Database Event Driven Motion Systems

ABSTRACT

A data collection system for distributing data from at least one target asset to at least one software application, comprising a machine platform and a data routing system. The machine platform stores data associated with the at least one target asset. The data routing system collects data from the machine platform. The data routing system operates in a pass through mode and a data processing mode. In the pass through mode, data is passed from the at least one target asset to the at least one software application without modification. In the data processing mode, the data routing system generates modified data based on the data stored by the machine platform and sends the modified data to the at least one software application.

RELATED APPLICATIONS

This application (Attorney's Ref. No. P216804) is a continuation of U.S.patent application Ser. No. 12/557,722 filed Sep. 11, 2009.

U.S. patent application Ser. No. 12/557,722 is a continuation of U.S.patent application Ser. No. 11/583,233 filed Oct. 18, 2006, nowabandoned.

U.S. patent application Ser. No. 11/583,233 claims priority benefit ofU.S. Provisional Patent Application Ser. No. 60/727,901 filed Oct. 18,2005.

U.S. patent application Ser. No. 11/583,233 is also acontinuation-in-part of U.S. patent application Ser. No. 11/505,056filed Aug. 15, 2006, now abandoned.

U.S. patent application Ser. No. 11/505,056 claims priority benefit ofU.S. Provisional Patent Application Ser. No. 60/708,699 filed Aug. 15,2005.

U.S. patent application Ser. No. 11/583,233 is also acontinuation-in-part of U.S. patent application Ser. No. 10/844,025filed May 12, 2004, now abandoned.

U.S. patent application Ser. No. 10/844,025 claims priority benefit ofU.S. Provisional Patent Application Ser. No. 60/506,104 filed Sep. 25,2003.

U.S. patent application Ser. No. 11/505,056 is also acontinuation-in-part of U.S. patent application Ser. No. 10/991,905filed Nov. 17, 2004, now abandoned.

U.S. patent application Ser. No. 10/991,905 claims priority benefit ofU.S. Provisional Patent Application Ser. No. 60/520,918 filed Nov. 17,2003.

The contents of all related applications listed above are incorporatedherein by reference.

TECHNICAL FIELD

The present invention relates to computer systems for collecting datafrom one or more disparate data sources and distributing the collecteddata to one or more disparate data destinations and distributingsoftware commands from one or more command sources to one or morecommand targets.

BACKGROUND

The present invention is used in the context of collecting anddistributing data and control commands in the context of motion controlmachines or devices. The present application uses the term “routing” torefer to the process of both collecting data from data origins anddistributing data to data destinations. The terms “data” and “dataitems” are used herein to refer to numeric, binary, or string datagenerated in an analog or digital format. Data is typically generated bymachines, devices, or the like forming part of a larger workingenvironment. The term “machine” as used herein refers to a physicalasset used to perform a predetermined task. The term “device” istypically applied to a machine with a relatively small footprint.

The data origin or origins thus may be formed by any machine or device(mobile or not) that stores data and which is either directly controlledby humans through a user interface or automatically controlled via acomputer based system. However, the present invention is of particularsignificance in the context of a working environment defined by a motioncontrol system, and that application of the present invention will bedescribed in detail below. The present invention may have broaderapplication to other working environments, however, and the scope of thepresent invention should be determined by the claims appended hereto andnot the following detailed description.

A motion control system typically comprises a plurality of motioncontrol machines or devices each programmed to perform an individualtask. The motion control system is configured to coordinate theindividual tasks so that the motion control system itself performs acombined task. In the context of motion control systems, controlcommands are transmitted to motion control devices such as computernumeric control (CNC) systems, general motion control (GMC) automationsystems, and hardware independent data engines for motion controlsystems. The term “command target” will be used to refer to anydestination motion control device or machine or any location on deviceor machine that can carry out a command using command data as describedherein. In some situations, these control commands come from a varietyof sources, which will be referred to herein as command sources.

Each motion control machine or device comprises a controller thatgenerates and/or stores data indicative of the state of the machine ordevice at a particular point in time. Typically, some or all of thisdata changes because the state of the machine changes as the machineperforms its individual task.

The data generated and/or stored by the motion control machines and/ordevices of a motion control system can be used to optimize theperformance of one or more of the individual machines as well as theentire motion control system. The data destinations where the data issent can thus take any one or more of a number of forms, including adatabase system, a plant floor process management system, software usedto optimize overall production flow, other software systems, and/oranother data routing system as described herein.

The collection and distribution of the data and control commandsassociated with individual motion control machines is, however,complicated by several factors. The sheer volume of data can overwhelmthe ability of the data destination to store and/or process the datacollected. In addition, the data origins and data destination may employdifferent, unique, or proprietary hardware and software systems thatutilize different data acquisition commands, data formats, and datatransmission protocols.

The need thus exists for data routing systems and methods that organizethe distribution of control commands form a variety of types of commandsources to a variety of types of command targets, facilitate thecollection of data from diverse data origins, and facilitate thesubsequent distribution of data to diverse data destinations.

SUMMARY

The present invention may be embodied as a data collection system fordistributing data from at least one target asset to at least onesoftware application, comprising a machine platform and a data routingsystem. The machine platform stores data associated with the at leastone target asset. The data routing system collects data from the machineplatform. The data routing system operates in a pass through mode and adata processing mode. In the pass through mode, data is passed from theat least one target asset to the at least one software applicationwithout modification. In the data processing mode, the data routingsystem generates modified data based on the data stored by the machineplatform and sends the modified data to the at least one softwareapplication.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 is a somewhat schematic block diagram of a data routing system ofa first embodiment of the present invention;

FIG. 2 is a somewhat schematic block diagram of a data routing system ofa second embodiment of the present invention, where the data routingsystem has been optimized for use with a motion control system;

FIGS. 3-8 are scenario maps depicting the interaction of one or morecomponents of the data routing system of FIG. 2 in different operationalscenarios;

FIGS. 9-19 are examples of user interface configurations that may beused by the example data routing system of FIG. 2;

FIGS. 20 and 21 are highly schematic block diagrams depicting alternaterelationships of data inputs, data outputs, and decision logic that maybe used by the example data routing systems of FIGS. 1 and 2;

FIG. 22 is a module interaction map depicting the interaction of modulesof a command processor system of a first embodiment of the presentinvention;

FIGS. 23-29 are use case maps illustrating common uses cases that occurduring operation of the example command processing system of FIG. 22;

FIG. 30 is a module interaction map depicting the interaction of modulesof a command processor system of a second embodiment of the presentinvention;

FIGS. 31-35 are use case maps illustrating common uses cases that occurduring operation of the example command processing system of FIG. 30;

FIG. 36 depicts a component interface implemented by all components ofthe example command processing system of FIG. 30;

FIG. 37 is a module interaction map depicting interactions of an exampledata routing system of the present invention with a machine platform,server platform, event system, database client, and/or commandprocessor;

FIG. 38 is a module interaction map depicting the process ofinitializing the data router database;

FIG. 39 is a module interaction map depicting the process ofinitializing the protocol server;

FIG. 40 is a module interaction map depicting the process of browsingfor items on the protocol server;

FIG. 41 is a module interaction map depicting the process of updatingdata;

FIG. 42 is a module interaction map depicting the process of readingdata; and

FIG. 43 is a module interaction map depicting an alternativeconfiguration of a data routing system that processes commands via thedata router database.

FIG. 44 is a module interaction map depicting a single assetconfiguration of a data collection system of the present invention;

FIG. 45 is a module interaction map depicting a multi-asset connectivityconfiguration of a data collection system of the present invention;

FIG. 46 is a module interaction map depicting a multi-asset andmulti-enterprise software connectivity configuration of a datacollection system of the present invention;

FIG. 47 depicts the flow of data though the data collection systemdepicted in FIGS. 44-46;

FIG. 48 is a highly schematic block diagram depicting the data‘pipe-line’;

FIG. 49 depicts further details of an example data router collection;and

FIG. 50 depicts the components making up the example MOTION.NET softwarethat may be used by the data collection systems of the presentinvention.

DETAILED DESCRIPTION I. First Embodiment Data Distribution

Referring initially to FIG. 1 of the drawing, depicted therein is a datarouting system 20 constructed in accordance with, and embodying, theprinciples of the present invention. The data routing system 20 is usedto route data or data items collected from data origins 22 to one ormore data destinations 24.

As described above, the terms “data” and “data items” will be usedherein to refer to numeric, binary, or string data values collected inan analog or digital format from a data origin 22. Examples of datatypes that represent data or data items as defined herein includeADDRESS, ARRAY, BIT, BYTE, WORD, DWORD, LONG, REAL, DOUBLE, FLOAT,BINARY BLOB, STRUCTURE, STRING, and ASCII STRING.

The data origins 22 are machines, devices, or the like forming part of alarger working environment. The working environment is not a part of thepresent invention and thus will not be described herein beyond what isnecessary for a complete understanding of the invention. The terms“machine” as used herein refers to a physical asset used to perform apredetermined task. The term “device” is typically applied to a machinewith a relatively small footprint.

Examples of machines as defined herein include a CNC mill used to shapemetal, a pick-n-place machine used to position parts on a circuit board,a robotic machine used to perform surgery, a medical data input device(i.e. blood glucose meter, asthma meter, etc), a gaming device, arobotic toy, an animatronics figure, a robotic machine used to delivergoods to a warehouse or to people, an automobile, a truck or farmvehicle, a boat or ship, an airplane, a jet, a helicopter, a spacecraft,and/or a hardware or software-based control system within a personalcomputer or even just a personal computer or hand-held computer itself.The data origin or origins thus may be formed by any machine or device(mobile or not) that stores data and which is either directly controlledby humans through a user interface or automatically controlled via acomputer based system.

As shown in FIG. 1, the data collected by the data routing system 20 isdelivered to one or more data destinations 24. The data destinations 24can take on many forms and serve many functions, but a primary functionof the data destinations 24 is to use the data collected from themachines in the working environment to optimize operation of theindividual machines and the overall working environment.

The example data routing system 20 is a software system that comprises adata input module group 30, an optional data cache module group 32, anda data output module group 34. The term “module” as used herein refersto a binary block of computer logic that contains functions, objects,components, ActiveX components, .NET source, HTML, XML and/or othercomputer code that can be executed in real-time or in script form.Several examples of a module include an executable EXE, a dynamic linklibrary DLL, an OLE component or set of components housed within a DLLor EXE, an ActiveX Control, an HTML or XML based Control, a VB scriptsource file, a Java Serverlet, Java Control, Java Object, .NET Package,etc.

The data input module group 30, data cache module group 32, and dataoutput module group 34 typically run on a processor forming part of acomputer system, but may be configured to operate across severaldiscrete processors forming part of one or more computer systems.

The data routing system 20 operates basically as follows. The data inputmodule group 30 communicates with one or more data origins 22 to obtaindata indicative of a state or condition of the machine or device formingeach of the data origins 22. If used, the data cache module group 32temporarily or persistently stores the data collected by the data inputmodule group 30. The data output module group 34 determines theconditions under which data collected by the data input module group 30stored in the data cache module group 32 is sent to one or more of thedata destinations 24. The data output module group 34 optionally alsodetermines the format in which data is sent to the data destination 24and/or the method of transporting the data to the data destination 24.

The example data input module group 30 comprises a data collectioncomponent 40 and one or more data source components 42. The term“component” as used herein refers to a logical organization of computercommands designed to perform an operation or set of operations. Examplesof components include OLE components, ActiveX controls, HTML or XMLbased controls, HTML or XML based objects, .NET objects, C++ objects, Cfunction set, Visual Basic objects, and the like. A component mayoperate on a single processor or may be distributed across a pluralityof processors.

The data collection component 40 associates all of the data collectedwith the data origins 22 from which the data was collected. The datacollection component 40 may be connected directly to one or more of thedata origins 22 or may be connected to one or more of the data origins22 through the data source components 42 as shown. If the datacollection component 40 is connected directly to a data origin 22, thedata collection component 40 and the data origin 22 must bepre-configured to work with each other, and the data collectioncomponent 40 is considered data origin independent, whereas the datasource component 42 is considered data origin dependent. However, if thedata collection component 40 communicates directly with a data origin22, it then becomes data origin dependent.

Preferably, however, one or more data source components 42 are providedto allow the data collection component 40 to operate in a data originindependent manner. In this case, the example data source components 42are each associated with one or more of the data origins 22. The datasource components 42 collect data from a particular data origin 22 orclass of data origins 22 and pass this data to the data collectioncomponent 40 in a predetermined format. The data source components 42may run entirely on the same processor or processors as the data routingsystem 20, entirely on a processor or processors associated with thedata origin 22, or on processors associated with both the data routingsystem 20 and the data origin 22. Although optional, the use of the datasource components 42 is preferred to isolate the data collectioncomponent 40 from the operational details of each of the data origins22.

The data input module group 30 may collect data from the data origins 22by one or more of a number of methods. For example, the data sourcecomponents 42 and/or data collection component 40 may read registervalues on the machine or device, read shared memory provided by themachine or device, send commands to the machine or device for which adata response is given containing the data requested, read variablesprovided by the machine or device, read and write to variables in asequence necessary to produce data values, query data using aproprietary or standard data protocol, call a function provided by themachine or device, build and send a command based on a protocol used tocommunicate with the machine or device for which a data response isprovided by the machine or device from which the data is extracted,and/or the like.

The optional data cache module group 32 comprises a data store component50 and at least one data cache 52. The data collection component 40passes data to the data store component 50; the data store component 50stores this data in one or more of the data caches 52. The data caches52 may be temporary or volatile memory devices such as RAM or may bepermanent or persistent memory such as a hard drive or database system.The data store component 50 further retrieves data from the appropriatedata cache 52 as necessary. If the data cache module 32 is not used,data collected by the data collection component 40 is passed directly tothe data output module group 34 in real time.

The data output module 34 comprises a data output component 60. Asmentioned, the data output component 60 may receive data directly fromthe data collection component 40. However, if the data cache module 32is used, the data output component 60 may direct the data storecomponent 50 to read data stored in one or more of the data caches 52and transfer the stored data to the data output component 60.

The data output module group 34 further comprises one or more datatransport components 62. Each of the data transport components 62defines or is associated with a method or system of transporting datafrom the data output component 60 to one or more of the datadestinations 24. The data output component 60 selects an appropriate oneof the data transport components 62 for each data element based on thedata destination 24 to which the data element is to be sent.

Optionally, the data output module group 34 further comprises a dataformatter component 64. The data formatter component 64 contains logic,templates, or the like for arranging data elements in a formatappropriate for one or more of the data destinations 24. The dataformatter component 64 allows the data destinations 24 to be implementedin a machine or device independent manner by obviating the need for thedata destinations 24 to process data elements in the format generated bythe data origins 22.

The data output module group 34 further optionally comprises aninference engine component 66. If used, the inference engine component66 helps the data output component 60 to determine the data destinationor destinations 24 where each data element is set. The inference enginecomponent 66 may further assist the data output component 60 to make thedetermination of which data is to be output (if any) and/or which datatransport component 62 to use and/or whether the data formattercomponent 64 is to be used.

The data routing system 20 of the present invention thus collects datafrom one or more data origins 22 and routes this data to one or moredata destinations 24. The use of the data routing system 20 allows thedata destination or destinations 24 to operate independent of theimplementation details of the data origin or origins 22. In addition,the data routing system 20 can be configured to be independent of thedata destination through the use of the data transport components 62,and data formatter components 64.

Turning now to FIGS. 2-21 of the drawing, depicted therein is a datarouting system 120 of the present invention. The example data routingsystem 120 operates in the same basic manner as the data routing system20 described above but is optimized to operate in a working environmentdefined by a motion control system.

FIG. 2 illustrates that the data routing system 120 is a collection ofmodules or components used to collect machine data from the data origins122 and then send some or all of the data collected to the datadestinations 124. The data destinations 124 may be either a local datadestination (for later replication to a remote data destination) or aremote site (either a remote data routing system or third party datadestination).

The example motion system 122 as defined in U.S. Pat. No. 5,691,897, butother motion systems may be used instead or in addition. As will bedescribed in further detail below, the motion system 122 defines or isassociated with one or more application programming interfaces. Themotion system 122 is not per se part of the present invention and willnot be described herein beyond what is necessary for a completeunderstanding of the present invention.

The data destinations 124 may use the data delivered by the data routingsystem 20 for a variety of purposes. A primary function of the datadestinations 124 is to optimize and/or monitor the operation of themachines and/or devices forming the motion control system that themotion services 122 or other software used by the data sources 142communicate with. The data destinations 124 can thus take any one ormore of a number of forms, including a database system, a plant floorprocess management system, software used to optimize overall productionflow, or other software systems, and/or another data routing system asdescribed herein.

The example data routing system 120 is connected to the data destination124 through a network 126. The network 126 is a combination of hardwareand software architectures that forms a link between two or morecomputer systems. Examples of network architectures include a packetbased network, a streaming based network, broadcast based network, orpeer-to-peer based network. Examples of networks that may be used as thenetwork 126 include a TCP/IP network, the Internet, an Intranet, awireless network using WiFi, a wireless network using radio waves and/orother light based signals, and the like.

The software components making up the example data routing system 120may be organized into three module groups: a data input module group130, a data cache module group 132, and a data output module group 134.The data input module group 130, data cache module group 132, and dataoutput module group 134 typically run on a processor forming part of acomputer system, but may be configured to operate across severaldiscrete processors forming part of one or more computer systemsconnected by a computer network.

The data input module group 130 comprises a data collection component140 and a plurality of data source components 142 a and 142 b. The datacache module group 132 comprises a data store component 150 and one ormore data cache components 152. The data output module group 134comprises a data output component 160, one or more data transportcomponents 162, a data formatter component 164, and an inference enginecomponent 166.

The data collection component 140 is responsible for collecting datafrom the machine asset and routing all data collected to the data cachemodule group 132. The data collection component 140 is responsible formanaging one or more data source components 142 for which data iscollected and route the data collected to the data cache module group132.

The data source components 142 a and 142 b communicate with the motionsystem 122. Each data source communicates with the motion system usingwhatever means are available including to the use of applicationprogramming interfaces (API) 170 a, 170 b, and 170 c associated with themotion system 122, using (API) provided by a motion system vendor, orusing network or other communication protocols. The example data sourcecomponent 142 a is configured to receive data from the API's 170 a and170 b, while the example data source component 142 b is configured toreceive data from the API 170 c.

The example data collection component 40 manages one or more data sourcecomponents 142 and is responsible for routing the data collected to thedata store component 150 of the data cache module 132. Optionally, eachdata collection component 140 may communicate directly to the motionsystem 122 without the need for an intermediary data source component142. However, the use of the data source component 142 allows for codereuse as the data collection component 140 may then implement all commonfunctionality, thus making each data source component 142 extremely thinand easy to build and maintain. In addition, the use of each data sourcecomponents 142 allows the data collection component 150 itself to beindependent of each data origin with which each data source component142 communicates to collect data.

Each data source component 142 is responsible for mapping the datacollected from the data source (i.e. XMC API, XMC CNC API, ProtocolServer, or proprietary data source) into the format expected by the datacollection component 140 and ultimately the data store component 150.The main goal of the data source components 142 is to provide aconsistent interface to the data origin 122, thereby freeing the clientfrom the details of the data origin 122 and allowing all data sourcecomponents 142 to act and operate in the same manner from theperspective of the data collection component 140.

The data cache module group 132 caches the data received so that it maylater be analyzed or otherwise processed. In particular, the data storecomponent 150 manages one or more data caches 152 and is responsible forstoring all data received and giving access to all data stored.Optionally, each data store component 150 could cache all data receiveddirectly without the need for an intermediary data cache 152. However,the use of the data cache or caches 152 allows for code reuse and alsoallows the data store component 150 to remain independent of any cachingtechnologies used by each data cache component 152. The data storecomponent 150 may then implement all common functionality, thus makingeach data cache module 132 also extremely thin and easy to build andmaintain.

The terms “primary data cache” and “secondary data cache” may be used torefer to one or more of the data caches 152 depending upon whethercertain features of the data cache module 132 are implemented and/orused as will be discussed in detail below. The suffix “a” is used inFIG. 2B to designate a primary data cache, and the suffix “b” is used todesignate a secondary data cache.

Each data cache 152 stores data in a data target 172 such as a databaseon a hard drive, RAM memory, or another persistent or volatile storagemedium. The term “data target” is used herein to refer to any device ormachine or location on a device or machine that can produce data asdefined herein. The main purpose of the data caches 152 is to provide aconsistent interface to the data storage medium used so that the caches152 appear to be the same to the user, thus freeing the client of anydetails handling various caching mechanisms.

The data output module group 134 is responsible for sending the datacollected by the data input module group 30 and/or stored by the datacache module group 32 to the data destination 122. The data outputcomponent 160 manages the other components forming the data outputmodule 34, namely, the data transport components 162, the data formattercomponent 164, and the inference engine component 166.

More specifically, the data output component 160 is responsible forsending data to one or more data destinations 124. As generallydescribed above, the data destination may be an enterprise datamanagement system, an artificial intelligence system, a plant floorprocess management system, software used to optimize overall productionflow, another data routing system such as the systems 20 and 120described herein, and/or other software systems used to optimize and/ormonitor how the overall factory operates based on how each machinemaking up the factory runs.

The inference engine component 166 is responsible for mapping the dataelements received from the data input module group 130 or data cachemodule group 132 through the data output component 160 to the datadestinations 124 to which the data elements are to be sent. The datatransport component 162 defines which data elements are to be sent towhich data destination 124. When performing this mapping, the inferenceengine component 166 also optionally provides a set of rules and/orother criteria that are used to determine whether or not each outputdefined by the data transport component 162 should ‘fire’. For example,the inference engine component 166 may use one or more of the followinglogic systems: artificial intelligence systems, fuzzy logic algorithms,neural network pattern matching, genetic algorithms, expert systemlogic, and/or other computer based decision-making and/or patternmatching based systems, to determine when a given set of one or moredata elements should be sent out. In the simplest case, an identitytransform may be used which causes all data inputs received to be sentout as matching data outputs.

The data formatter component 164 is used to format all or portions ofthe data set to be transported to the data destinations 124. For examplethe data formatter component 164 may be used to format data output bythe inference engine component 166 into a certain XML schema or otherproprietary data format.

The data transport component 162 is responsible for sending the data tothe ultimate data destination 124, including an enterprise database, anenterprise software system, or even another data routing system such asthe data routing system 120.

Referring still to FIG. 2, also depicted therein is a data manager 180that allows the user to manage operation of the data routing system 120.The data manager 180 controls access to property pages exposed orgenerated by user-interface components associated with the components140, 150, 160, 162, 164, and 166. Property pages may also be exposed orgenerated by user interface components associated with the components142 and 152. In particular, the example data routing system 120comprises data collector property pages 182, data store property pages184, data output property pages 190, data transport property pages 192,data formatter property pages 194, and inference engine property pages196. As will be described in further detail below, the property pages182, 184, 190, 192, 194, and 196 allow the user to initialize,configure, and control the components 140, 150, 160, 162, 164, and 166,respectively.

In the following discussion and in the drawings, the property pages 182,184, 190, 192, 194, and 196 also refer to the user-interface componentsassociated with these property pages. The property pages 182, 184, 190,192, 194, and 196 and other interface elements are separated from thecomponents 140, 150, 160, 162, 164, and 166 in the system 120 tooptimize the overall system flexibility and facilitate evolution towardnew and future user interface technologies such as HTML based web userinterface, SOAP/XML based interfaces, Microsoft .NET based interfaces,etc. Optionally, however, the components 140, 150, 160, 162, 164, and166 could directly expose property pages and other user-interfaceelements.

Referring now to FIGS. 3-8, the interactions of the components andproperty pages forming the data input module group 130, data cachemodule group 132, and data output module group 134 will now be describedin further detail in the various scenarios required to implement thefunctions of the example data routing system 120.

Before using the data routing system 120, the system must first beinitialized. During initialization, all components are started andconfigured with their initial settings. Initializing the system involvesconfiguring the data routing system 120 so that it knows what data tocollect, where to collect it from, how to process the data collected andwhere to send the processed data. Once initialized, the system is readyto begin collecting, storing and processing machine and/or device data.

The initialization process includes to levels. First, the overall datarouting system 120 must be configured by connecting one or more datacollection components 140 data and one or more data output components160 to the data store component 150. Once connected, the componentsmaking up each of the data input module 130, data output module 134, anddata cache module 132 groups must next be configured.

The process of initializing the data routing system 120 will now bedescribed with reference to FIG. 3

Initially, the data manager 180 is run to configure the overall system120.

The data manager 180 of the data routing system 120 next uses the datastore property pages 184 paired with the data store component 150. Thedata store property pages 184 query the data store component 150 for allentries in the data output module group 134 category (or optionallyqueries for each entry directly using the OLE Component Categories) anddisplays each entry visually in the property page 184.

Next, after the user selects which data output module or systems 134 toactivate, the list of active data output components 160 associated withthe selected data output module or systems 134 is sent back to the datastore component 150 so that it may use the active components. The datastore component 150 could optionally query a separate ‘configuration’component used to select the active data output modules 134 to use laterwhen processing data to be output. Additionally, the activation of eachactive component 160 may optionally be activated programmaticallyinstead of by the user.

During its initialization, the data store component 150 creates aninstance of each activated data output component 160 so that the datastore component 150 can send data update events to each upon receivingnew cache data.

Similar to the configuration of the data output module group 134, thedata store property pages 184 query the data input module group 130 fora list of supported data collection components 140. Optionally, the datastore component 150 may query the data collection components 140 of thedata input module group 130 and display each these data collectioncomponents 140 visually so that the user can activate all components 140that are appropriate for collecting data.

Once selected visually by the user, the active list of one or more datacollection components 140 is sent to the data store component 150.Optionally, the data store component 150 could query a separate‘configuration’ component used to select the active data output modules134 to use later when processing data to be output. Additionally, theactivation of each component may optionally be activatedprogrammatically instead of by the user.

During initialization, the data store component 150 creates an instanceof each active data collection component 140.

Once the main components data store component 150, data collectioncomponent 140, and data output component 160 of the data output module134 are configured, the user (or configuration program) must configurethe components used by each of the systems 140, 150, and 160. The mainconfiguration task for the data collection component 140 is that ofselecting the data source components 142 (and the data items supplied byeach) from which data is to be collected. The process of configuring thecomponents used by the systems 140, 150, and 160 will now be describedwith reference to FIG. 4.

The following steps take place when configuring the data collectioncomponent 140 and related components.

First, the data manager 180 is used to configure the data collectioncomponent 140.

Second, the data collector property pages 182 are used to configure thedata collection component 140. Optionally, all configuration may be doneprogrammatically by another software module.

Each of the data collector property pages 182 queries the Data SourceOLE Category of components to see what data source components 142 areavailable. Optionally, the data collection component 140 may be queriedfor the list of all data source components 142 available.

A visual list of available data source components 142 is nextconstructed, thus allowing the user to select which data sourcecomponent or components 142 to use when collecting data. Optionally, thedata collection component 140 could directly talk to the data sourcecomponents 142; however such direct communication would reduce codereuse as the data collection component 140 allows each data sourcecomponent 142 to be very thin, making these components 142 easy to buildand maintain.

Finally, after the user selects the data source components 142 to use, alist of active data source components 142 is passed to the datacollection component 140, which then creates an instance of eachselected component.

Optionally, each data source component 142 may use an associatedproperty page (not shown) that allows the user to visually (or softwareto programmatically) configure and select the data inputs from whichdata is to be collected by each data source component 142. Each datacollector component 140 may also define a set of data inputs that theuser may configure and select; however this it not optimal as the datasource components 142 allow each data collector component 140 to remainindependent of how each data origin actually works; i.e. the data itemsthey provide and how the data for each data item is actually collected.

Referring now to FIG. 5, the following steps take place when configuringthe data cache module group 132, which includes the data store component150 thereof. Configuring the data store component 150 requires theselecting of the data cache 152 to use. When caching data there arethree main methods that may be employed: (1) cache all data to memoryonly; (2) cache all data to a persistent storage such as a database, or(3) a mixture where data is initially cached to memory and then‘rolled-over’ into the persistent store at certain intervals or after aspecified amount of data has been collected. All three models areutilized by the data cache module group 132 of the data routing system120, where only one method is necessary to build a picture of theoverall state of the data origin at a given moment in time.

In a first step shown in FIG. 5, the data manager 180 of the datarouting system 120 is used to configure the data store component 150 andassociated components using the embedded data store property page 184.As described above, the data store component 150 can be configured toimplement all user aspects that it needed to edit and otherwise allowthe user interact with the data and configuration managed by thecomponent. However, separating the user interface from the component ina parallel component has several advantages that allow for easilyadopting future user-interface based technologies such as HTML, Windows.NET, and thin client. For these reasons the user interface hasoptionally been separated from the main logic making up the data storecomponent 150. As generally described above, this same designorganization is used throughout the entire system 120 by all componentshaving an associated property page.

The data store property page 184 component queries the data storecomponent 150 for the list of data cache components 152 that areavailable and displays the list visually. The list of availablecomponents 152 may optionally be provided programmatically by a separatecomponent used for configuration. As an additional option, the datastore property page 184 may directly query the Cache Category ofcomponents in the OLE Component Category.

From the data store property page 184, the user visually selects thespecific data cache components 152 to use and the specific cachingstrategy to employ (single caching or roll-over where data from onecache is rolled over to another cache based on certain criteria such asan interval of time, or a data cache data threshold being met). Theselected data cache components 152 and strategy selected by the user aretransferred to the data store component 150 which then stores thesettings.

Each data output component 160 and associated components act as a dataoutput ‘pipeline’ where data follows a set of steps that determines whatdata will be output, what format that data will be output in, and wherethe data will be sent. Referring now to FIG. 6 of the drawing, depictedtherein are the steps that take place when configuring the data outputcomponent 160 and its related components.

First, the data manager 180 is used to configure the various aspects ofthe data output component 160 and its associated components.

When configuring the data output component 160, the data output propertypage 190 parallel component acquires the list of inference enginecomponents 166, data formatter components 164, and data transportcomponents 162 that are available. Once the list of data transport, dataformatter, and inference engine components 162, 164, and 166 isacquired, a visual display of the list is created on the data outputproperty page 190 so that the user can select one or more of thecomponents 162, 164, and 166 from the list as appropriate for theirapplication.

To obtain this list of components, the data output property page 190 mayeither query the data output component 160 or directly query the OLECategory for each of the data transport component 162, data formattercomponent 164, and inference engine component 166. If the data outputcomponent 160 is queried for the list of available components in eachcategory, the data output component 160 in turn may then internallyquery a pre-configured list or the OLE components falling into eachrespective OLE Category for the data transport component 162, dataformatter component 164, and inference engine component 166.

After the user selects one or more data transport components 162, one ormore data formatter components 164, and one or more inference enginecomponents 166, the list of components to activate is sent to the dataoutput component 160, which stores the component information as itsactive components and then creates an instance of each component.

Next, each data transport component 162 is queried for its list ofsupported outputs. The list of supported data outputs is then passed tothe inference engine component or components 166 selected.

Next, the data output component 160 queries the data store component 150for its list of supported data items, usually stored in the data cachecomponents 152 and previously selected when configuring the datacollection component 140. The list of supported input data items is thenpassed to the inference engine component or components 166 selected.

When the inference engine component or components 166 have both theinputs and outputs available, the user may optionally configure rules orother criteria used to determine when each output is ‘fired’ based onthe input data received. As examples, one or more of a set of FuzzyLogic rules, a previously trained Neural Network pattern, a GeneticAlgorithm fitness, Expert System logic, or other custom logic may beused to determine when certain outputs are sent through the data outputpipeline to the data destination.

In addition, the data formatter component or components 164 may also beconfigured to output data in data formats supported by each datadestination 124. For example, a data formatter component 164 may be usedto output data items received in a certain proprietary schema. However,the data formatter component 164 would need to be configured so that itwould know how to match the data items received to the proprietaryschema. This step in the configuration process would allow the user, oranother software program, to make this configuration.

And finally, the data transport component or components 162 would needto be configured so that they could properly send data received to theend data targets that it supported. For example, a data transportcomponent 162 configured to use TCP/IP may need to have target TCP/IPaddresses configured or TCP/IP ports configured telling the component 42where to send the data.

Once initialized, the data routing system 120 is ready to startcollecting data and storing all data collected as previously configured.FIGS. 7A and 7B depict the interactions that take place when collectingdata.

First each data source component 142 either polls for data or receivespreviously configured events from its data origination. For example,when using the motion system 124 or a Protocol Server as the dataorigin, events may be received telling the data source component 142that new data is available.

Upon receiving a data update event, the data source component 142 firesan event to its respective parent data collection component 140.

Upon receiving its event, the data collection component 140 then firesan event to the data store component 150.

Upon receiving each data update event, the data store component 150 usesthe active caching component or components 152 to store the data.Optionally, the data cache module 132 may employ a roll-over strategy inwhich data received is passed to one or more data cache modules 132after a certain criteria is met such as in interval of time passing or adata caching threshold being met.

After caching the data, the data store component 150 fires a data updateevent to any data output component or components 160 connected to thedata store system 132.

Upon receiving the data update event, the data output component 160 mayoptionally query the data store component 150 for more data if needed togain a full description of the current state of the machines forming themotion system 122.

All data input information is then passed to the inference enginecomponent 166 for processing. Upon receiving the data, the inferenceengine component 166 runs its preconfigured rule set against the dataset received and produces the output (if any) that is eligible to besent to the data destinations 124. If the inference engine component 166employs a dynamic model of the data, its internal model may alter itselfbased on the input data received. For example, an inference enginecomponent 166 that uses a neural network may ‘learn’ from the data bychanging the neural network's weights based on the data input valuesreceived.

If data is eligible to be output, and a data formatter component 164 isused, the output data received from the inference engine component 166is then sent to the data formatter component 164. Upon receiving thedata, the data formatter component 164 transforms the data received intothe supported output data format and passes the new output data back tothe data output component 160.

The formatted data is then passed to the data transport component orcomponents 162 to be transported or sent to the data destinations 124.If a data formatter component 164 is not used, the raw data formatoutput from the inference engine component 166 is used and passeddirectly to any active data transport component 162. Upon receiving theoutput data, the active data transport component or components 162 sendthe data to their respective data destinations 124. For example, aTCP/IP transport would packetize the data into TCP/IP packets and sendthe data stream to a preconfigured TCP/IP address/port. Alternatively, awireless transport may broadcast the data out on a pre-configuredfrequency.

Referring now to FIG. 8 of the drawing, depicted therein is arelationship among the interface windows and dialogs that form theproperty pages used to configure the example data routing system 120.The data manager 180 presents to the user a main window 220 (FIG. 9)that is used to access the data property pages 182, 184, 190, 192, 194,and 196 used to configure all settings of the data collection component140, data store component 150, and data output component 160 forming upthe system 120.

The example main window 220 presented by the data manager 180 toconfigure each of the main components 140, 150, and 160 is shown in FIG.9. In particular, the main page 220 of the data manager 180 acts as acontrol panel that allows the user to configure and monitor how dataflows from each data source 122 to the eventual data destination 124.

Each of the user interface elements of the main page 220 on the datamanager 180 will now be described with reference to FIG. 7.

A “Configure” button 222 allows the user to configure the overall system120 by building up the overall data transfer pipeline. This option isonly available when running the application as an Administrator on thesystem.

A “Start” button 224 starts monitoring the data source components 142and feeds the data received through the system 220.

A “Stop” button 226 stops monitoring the data source components 142 andshuts down the entire monitoring process.

A “Monitoring” icon 230 visually displays whether or not monitoring iscurrently enabled.

A “Close” button 232 closes the monitoring application window but doesnot close the application. Since the application runs as a system trayapplication, you must exit the application by right clicking on thesystem tray icon.

A “Status” window 234 visually shows the overall configuration andstatus of the system including all nodes making up the data input module130, data store system 132, and data output module 134.

The following sections describe how to build and configure the overallsystem 120 using examples of the various property pages 182, 184, 190,192, 194, and 196.

Referring initially to FIG. 10, depicted therein is a configurationdialog window 240 that is associated with the data manager 180. Theconfiguration dialog window allows a user to build the overall datarouting system 120. The user interface elements making up theconfiguration dialog window 240 are as follows.

An “Add Data Collector . . . ” button 24 displays a dialog containing alist of all data collection components 140 available to the system. Onceselected, the selected data collection components 140 are added to thesystem 120. The data collection components 140 are connected to the datastore component 150 so that data events are sent to the data storecomponent 150 each time data items are received by each of the datacollection components 140 from their respective various data sourcecomponents 142.

An “Add Data Output . . . ” button 244 displays a dialog containing alist of all data output modules 134 available to the system. Onceselected, the data output modules 134 are added to the system. Each dataoutput module 134 manages a data pipeline that may involve inferencerules or other decision-making technology that tell when to fire eachdata output.

A “Delete” button 246 removes a module from the list of componentsmaking up the overall data routing system 120.

A “Load” button 250 loads the components of a previously saved datarouting system 120 from a persistent storage medium such as a file ordatabase.

A “Save” button 252 saves the current data routing system 120 to apersistent storage medium such as a file or database.

A “Close” button 254 closes the configuration dialog.

A “Node” control 260 contains the current modules making up the datarouting system 120, including data collection components 140, data storecomponents 150, and data output components 160.

An “About” property page 262 displays information about the currentlyselected module in the node list.

A “Settings” property page 264 displays a property page corresponding tothe currently selected node in the node list. The property page allowsthe user to configure the settings specific to the node selected.

Examples of interface elements that may be used to implement theproperty pages 182, 184, 190, 192, 194, and 196, as well as otherrelated property pages, will now be described with reference to FIGS.11-18. The “Delete”, “Load”, “Save”, and “Close” interface elementsdepicted in FIGS. 11-18 apply to the “Node” Control on the left part ofeach figure (not shown) and will not be described in detail below.

An example of the data collector property page 182 is depicted in FIG.11 of the drawing. The data collector property page 182 allows a user toconfigure the components, such as the data collection components 140and/or data source components 142, of the data input module group 130.

A “Data Sources” list box 270 contains a list of all data sourcecomponents 142 available to the system. The list of available datasource components 142 is acquired by either directly enumerating theData Source OLE Category of components or by querying the datacollection component 140 for all data source components 142 that it‘knows’ about.

A “Select” button 272 adds the currently selected item in the list ofdata source components 142 to the currently selected data output module134 in the main node list.

A “Target Scan Rate” edit field 274 allows the user to input a globalscan rate that applies to all data source components 142 that may becontrolled using a global scan rate.

A data source property page 280 is depicted in FIG. 12. The data sourceproperty page 280 allows the user to select the data items madeavailable by each data source component 142. The selected data items arethen fed into the data store component 150 and eventually on into theselected inference engine component 166. The following user-interfaceelements make up the data source property page 280.

A “Data Items” list box 282 contains a list of all data items madeavailable by each data source component 142. The user must enable thedata items that they want to monitor in their system. The list ofavailable data items is acquired by browsing a particular data sourcecomponent 142.

A “Scan Rate” edit box 284 allows the user to enter the scan rate to usefor this specific data source (which may be different from the globalscan rate). If no scan rate is entered, the default global scan rate isused when appropriate.

A data store property page 290 depicted in FIG. 13 is used to configurethe data store component 150 by selecting and configuring the data cacheor caches 152 used and the specific caching strategies for each. Thefollowing user-interface elements make up the data store property page290.

A “Data Caches” list box 292 contains a list of all data caches 152available to the system 120. The list of available data caches 152 maybe acquired either by directly enumerating the data cache OLE Categoryof components or by querying the data store component 150 for a list ofactive data caches 152.

A “Select” button 294 adds the currently selected item in the “DataCaches” list box 290 to the currently selected data store component 150in the master node list.

Referring now to FIG. 14, depicted therein is a data cache property page320 that allows the user to configure the specific caching strategy tobe used by each data cache 152. The following user interface elementsmake up the data cache property page 320.

An “Enable data roll-over” check-box 322 allows the user toenable/disable data roll-over. When enabled, data placed in a particulardata cache 152 can roll-over into another, or secondary, data cache 152upon meeting certain criteria specified by other of the user-interfaceelements forming the data cache property page 320.

An “After reaching cache data threshold of” radio button 224, ifselected, determines that roll-over occurs when a certain number ofbytes are cached in the primary data cache, assuming that data cacheroll-over is also enabled by check box 322. A caching threshold datafield 324 a allows the user to specify the data cache threshold. Afterreaching the roll-over threshold level, all data currently in theprimary data cache 152 a is copied to the secondary data cache 152 b.

An “After time interval of” radio button 326, when selected determinesthat roll-over occurs at specifically set time intervals, again assumingthat data cache roll-over is enabled by check box 322. A time intervaldata field 326 a allows the user to specify the duration of the timeinterval. Upon the expiration of each time interval all data in theprimary data cache 152 a is automatically copied over to the secondarydata cache 152 b and then removed from the primary cache 152 a.

A “Roll-over to” list-box 328 contains a list of data caches that can beused as secondary caches 152 b. The primary cache 152 a rolls data overto the secondary cache 152 b selected by pressing a “Select” button 328a.

Referring now to FIG. 15, the data output property page 190 is depictedtherein in further detail. The data output property page 190 is used toconfigure the data output module 134 by selecting the data transportcomponents 162, data formatter component 164, and inference enginecomponent 166 that are to make up the data output pipeline. Thefollowing user-interface elements make up the data output property page190.

An “Interface Engines” list-box 330 contains a list of all inferenceengine component or components 166 that are available to the system 120.A first “Select” button 330 a allows one or more of the inference enginecomponents 166 to be selected. As generally described above, eachinference engine component 166 is responsible for mapping input valuesto output values and determining when each data element should actuallybe sent to the data destination 124.

A “Data Formatters” list-box 332 contains a list of all data formattercomponents 164 that are available to the system 120. A second “Select”button 332 a allows one or more of the data formatter components 164 tobe selected. Each data formatter component 164 is responsible fortransforming data input into another data format that is output asoutput data.

A “Data Transports” list-box 334 contains a list of all data transportcomponents 162 that are available to the system 120. A third “Select”button 334 a allows one or more of the data transport components 162 tobe selected. Each data transport component 162 is responsible forsending the data received to the ultimate data destination 124, such asan enterprise database, analysis system, another data routing system, orthe like.

The inference engine property page 196 will now be described in furtherdetail with reference to FIG. 16. The inference engine property page 196is used to configure the settings defining how the inference enginecomponent 166 actually works. The inference engine component 166 mapsinputs received to expected outputs defined by the data transportcomponent 162. When mapping inputs to outputs, the inference enginecomponent 166 optionally uses decision logic to determine whether or noteach output should fire (i.e. be sent on to one or more data transportcomponent 162) based on the inputs received. The user interface elementsmaking up the inference engine property page 196 are as follows.

An “Input Data Items” list-box 340 contains a list of all data inputsreceived from the data input module 130 via the data store component150. An “Output Data Items” list-box 342 contains a list of all dataoutputs received from the data output module 134 via the data transportcomponent 162. A “Rule Map” list-box 344 contains a list of rules thatdefine how to map the received data inputs to the outputs.

In this sample inference engine component 166, the user drags items fromthe Input Data Items list box 340 into the inputs making up the rule-mapas listed in the Rule Map list box 344. The rule-map associated witheach of the items in the Input Data Items list box 344 defines when tofire output to each defined output.

An example data formatter property page 194 is depicted in FIG. 17. Thedata formatter property page 194 allows the user to configure how thefinal data output is actually formatted. For example, the exampleproperty page 194 depicted in FIG. 17 illustrate how to map data outputsinto an XML schema. The following user interface elements make up thedata formatter property page 194.

An “XML Schema Map” 350 control contains an editable XML Schema thatallows a user to drag an output data item into different portions of theschema essentially ‘linking’ the data item to that portion of the XMLschema. When linked, the final XML data file is built by using the XMLschema and then placing data from each output data item into the slotswhere they are linked into the XML schema.

An “Output Data Items List” list-box 352 contains a list of all dataoutputs available as defined by the data output module 134 via the datatransport component or components 162.

Depicted in FIG. 18 is an example of a data transport property page 192.The data transport property page 192 allows the user to configure thespecific settings of each data transport component 162 used tocommunicate with the data destination or destinations 124. The exampleproperty page 192 depicted in FIG. 18 is an example property page for adata transport component 162 that communicates across a TCP/IP based(wire-based or wireless) network. The data transport property pageemploys the following user interface elements.

A “Target TCP/IP Address” 360 edit field allows the user to enter thetarget TCP/IP address of the machine or machines forming destinationswhere data is to be sent.

A “Target TCP/IP Port” edit field 362 allows the user to specify a setof one or more TCP/IP ports to use on the target TCP/IP address.

A “Use UDB Broadcasting” radio button 364 directs the transport tobroadcast the output data using the UDP broadcasting protocol and ignorethe target TCP/IP address as data will be sent to all machines formingdata destinations 124 on the network 126.

A “Use Peer-to-Peer Messaging” radio button 366 directs the transport touse a peer-to-peer messaging protocol such as the one used with WindowsInstant Messenger, where data is sent immediately to the target machineforming the data destination 124 and may optionally be displayed in anInstant Messenger viewing application such as Windows Messenger.

A “Use Data Streaming” radio button 368 directs the transport to use adata streaming technology where the data outputs are streamed to thetarget(s) in a manner similar to that of a streaming music or videosource. Optionally, the data outputs may also be interleaved into anexisting music, video, or other data streaming data source.

A “Use Virtual Private Networking Tunneling” radio button 370 directsthe transport to use a tunneling technology, where the data packetsmaking up the output data are embedded within another packet type,optionally encrypted and secured, and then sent to the target overanother protocol such as HTTP, or in this case the PPTP or L2TPprotocol. SOAP or XML messaging is another manner of tunneling where thedata is placed within a SOAP or XML ‘envelope’ and then sent over to theoutput target using the SOAP or other XML messaging protocol.

A “Use SMTP E-Mail Format” radio button 372 directs the transport topackage the output data sets into an e-mail format and sends it to thetarget. Further configuration may be required to actually setup aspecific e-mail address for the recipient.

A “Use SNMP Format” radio button 374 directs the transport to use theSNMP transport to communicate with the output target.

An “Enable Data Encryption” check-box 380 enables data encryption suchthat the data is encrypted before transmission. A “Use KerberosSecurity” check-box 382 enables Kerberos security. A “Use 128 bitEncryption” check-box 384 enables 128-bit encryption for the output datapackets.

An “Enable Transmission Timeout” check-box 386 enables transmissiontime-out on each communication with the target. When enabled, the senderonly waits for an amount of time specified in a data field 386 a for aresponse from the data destination 124, after which response datareceived from the target is ignored.

The example data routing system 120 is a modular system made up of a setof components as generally described above. In this case, each componentis based on a component technology, such as OLE/COM technology definedby Microsoft Corporation.

Optionally, each component uses a separate ‘parallel’ ActiveX componentto implement all user interface aspects of the main component, also asgenerally described above. Each ActiveX component may be implementedeither within the main component module or separately in its own module.Bundling each object within one module is not required as they may belocated at any location (i.e. across a network, and so forth), but doingso may optimize all communication between modules. How and wherecomponents are implemented is more of a logistical decision because,once components are built and deployed to the field, it is difficult toupdate a single component if all components are implemented within asingle DLL or EXE module.

FIG. 19 illustrates that the components forming the data routing systemconform to a single interface identified as the IXMCDirect interface.OLE Categories are used to determine how many components fall into acertain group of components. Components used by the example data routingsystem 120 fall into the following categories:

-   -   Data Input Components—Typically, this category includes a single        data collector component, but multiple data input components may        be used in a large distributed environment.    -   Data Source Components—Many data source components are often        used at the same time.    -   Data Output Components—Many data output components are often        used at the same time, with each data output component defining        at least part of a data output pipeline.    -   Inference Components—One or more inference engine components are        used by each data output component.    -   Data Formatter Components—One or more data formatter component        components are typically used by each data output module.    -   Data Transport Components—One or more data transport components        are typically used by each data output module.

The IXMCDirect interface depicted in FIG. 19 is used for mostcommunications between components of the data routing system 120. TheIXMCDirect interface is made up of the following functions, which arespecified in standard OLE/COM IDL format.

-   -   A GetProperty method is used to query a specific property from        the component implementing the interface.    -   A SetProperty method is used to set a specific property from the        component implementing the interface.    -   An InvokeMethod method is used to invoke a specific action on        the component implementing the interface. An action can cause an        event to occur, carry out a certain operation, query a value,        and/or set a value within the component implementing the method.

More detailed descriptions of each of the methods implemented by objectsimplementing the example IXMCDirect interface are described below.

The IXMCDirect::GetProperty method is used to query the propertycorresponding to the property name ‘pszPropName’. Each component definesthe properties that it supports. The following table summarizes theGetProperty method implemented by the example IXMCDirect interface:

Syntax HRESULT GetProperty( LPCTSTR pszPropName,   LPXMC_PARAM_DATArgData,   DWORD dwCount ); Parameters LPCTSTR pszPropName - string nameof the property to query. LPXMC_PARAM_DATA rgData - array ofXMC_PARAM_DATA types that specify each parameter corresponding to theproperty. For example, a certain property may be made up of a number ofelements - in this case an array of XMC_PARAM_DATA items is returned,one for each element making up the property. In most cases a property ismade up of a single element, thus a single element array is passed tothis method. For more information on the XMC_PARAM_DATA type, see below.DWORD dwCount - number of XMC_PARAM_DATA elements in the rgData array.Return HRESULT - NOERROR on success, or error code on Value failure.

The IXMCDirect::SetProperty method is used to set a property in thecomponent corresponding to the ‘pszPropName’ property. For the set ofproperties supported by the component, see the specific componentdescription. The following table summarizes the SetProperty methodimplemented by the example IXMCDirect interface:

Syntax HRESULT SetProperty( LPCTSTR pszPropName,   LPXMC_PARAM_DATArgData,   DWORD dwCount ); Parameters LPCTSTR pszPropName - string nameof the property to set. LPXMC_PARAM_DATA rgData - array ofXMC_PARAM_DATA types that specify each parameter corresponding to theproperty. For example, a certain property may be made up of a number ofelements - in this case an array of XMC_PARAM_DATA items is returned,one for each element making up the property. In most cases a property ismade up of a single element, thus a single element array is passed tothis method. For more information on the XMC_PARAM_DATA type, see below.DWORD dwCount - number of XMC_PARAM_DATA elements in the rgData array.Return HRESULT - NOERROR on success, or error code on Value failure.

The IXMCDirect::InvokeMethod method is used to call a specific methodimplemented by the component. For more information on the methodssupported, see the description of the specific component. The followingtable summarizes the InvokeMethod method implemented by the exampleIXMCDirect interface:

Syntax HRESULT InvokeMethod( DWORD dwMethodIdx,   LPXMC_PARAM_DATArgData,   DWORD dwCount ); Parameters DWORD dwMethodIdx - numbercorresponding to the specific method to invoke. For more information onthe method indexes available, see the set of namespaces defined for thecomponent. LPXMC_PARAM_DATA rgData [optional] - array of XMC_PARAM_DATAtypes that specify each parameter for the method called. For moreinformation on the XMC_PARAM_DATA type, see below. NOTE: if noparameters exist for the method called, a value of NULL must be passedin. DWORD dwCount [optional] - number of XMC_PARAM_DATA elements in thergData array. NOTE: if no parameters exist for the method called, avalue of 0 (zero) must be passed in for this parameter. LPXMC_PARAM_DATArgData [optional] - namespace associated with the instance of the customextension module added. Return HRESULT - NOERROR on success, or errorcode on Value failure.

This methods supported by each component making up the system 120 willnow be described. Initially, the general methods supported by themajority of the components forming the system 120 will be first bedescribed; the methods supported by each individual component will thenbe discussed.

The XMC_DE_BROWSE_GET_COUNT general method returns the number of dataitems in the browse set supported by the component and is described inthe following table.

Index 8020 Data In None Data Out rgData[0]-(number) DWORD, number ofbrowse elements.

The XMC_DE_BROWSE_GET_ITEMS general method returns the number of dataitems in the browse set supported by the component and is described inthe following table:

Index 8021 Data In rgData[0] - (number) DWORD, maximum number ofelements to collect. Data Out rgData[0] - (number) number of elementscollected, total number of elements will equal (rgData[0] * 2 + 1).rgData[1] - (string) name of the first browse element. rgData[2] -(number) adt of the first browse element. rgData[1 + n*2] - (string)name of the n′th browse element. rgData[ 2 + n*2] - (number) adt of then′th browse element.

The XMC_DE_SYSTEM_CONNECT_CMPNT general method is used to connect oneserver to another so that they may interact with one another and isdescribed in the following table:

Index 8000 Data In rgData[0] - (number) DWORD, type of component. Thetype of component is a value that is server specific. For component typeinformation, see the description for this method under each server'sdescription. rgData[1] - (string LPTSTR, component class id as an ASCIIstring. Data Out None.

The XMC_DE_SYSTEM_DISCONNECT_CMPNT general method is used to disconnectone server from another so that they stop interacting with one anotherand is described in the following table:

Index 8001 Data In rgData[0] - (number) DWORD, type of component. Thetype of component is a value that is server specific. For component typeinformation, see the description for this method under each server'sdescription. rgData[1] - (string) LPTSTR, component class id as an ASCIIstring. Data Out None.

The XMC_DE_DATA_PROCESS general method is called by a client to processdata where a data set is input, processed in some way by the server, andthen the resulting data is returned as output. The XMC_DE_DATA_PROCESSmethod is described in the following table:

Index 8063 Data In rgData[0] - (number) DWORD, number of data itemsinput. rgData[1 + n*2] - (string) LPCTSTR, name of the data item input.rgData[2 + n*2] - (number or string), value of the data item. Data OutrgData[0] - (number) DWORD, number of data items output. rgData[1 +n*2] - (string) LPCTSTR, name of the data item output. rgData[2 + n*2] -(number) value of the data item.

The XMC_DE_DATA_PROCESS_CONFIGURE general method is used to configurewhat type of data is returned when processing a given data item. Forexample in the server may be configured to return the minimal amount ofdata on each read (i.e. just the data item value), or the server may berequested to return more substantial data. TheXMC_DE_DATA_PROCESS_CONFIGURE method is described in the followingtable:

Index 8062 Data In rgData[0]—(number) DWORD, flag describing the type ofdata to be returned when processing data. The following flags aresupported: XMC_DE_READ_DATA_FLAG_TIMESTAMP—requests that the time stamprecorded when processing the data is returned. NOTE: by default, thedata item value is always returned. Data Out None.

The XMC_DE_DATA_READ general method is called by a client application topoll for data from the server and is defined in the following table:

Index 8061 Data In rgData[0]—(string) LPCTSTR, name of the data item toread. Data Out rgData[0]—(number or string), data item value.rgData[1]—(OPTIONAL number) DWORD, data item time- stamp as a systemtime value. NOTE: Since the last items are optional, only those itemsspecified when configuring the data to receive are actually sent.

The XMC_DE_DATA_READ_CONFIGURE general method is used to configure whattype of data is returned when reading a given data item. For example,the server may be configured to return the minimal amount of data oneach read (i.e. just the data item value) or the server may be requestedto return more substantial data. The following table defines theXMC_DE_DATA_READ_CONFIGURE method:

Index 8060 Data In rgData[0]—(number) DWORD, flag describing the type ofdata to be returned on each read. The following flags are supported:XMC_DE_READ_DATA_FLAG_TIMESTAMP— requests that the time stamp recordedwhen reading the data is returned. NOTE: by default, the data item valueis always returned. Data Out None.

The XMC_DE_DATA_WRITE general method is used to write data to a serverand is described in the following table:

Index 8064 Data In rgData[0]—(number) DWORD, number of data items.rgData[1 + n*2]—(string) LPCTSTR, name of the data item. rgData[2 +n*2]—(number or string), value of the data item. Data Out None.

The XMC_DE_EVENT_ENABLE general method enables/disables a previouslysubscribed data item in the subscription list maintained by the server.Only enabled subscriptions actually fire. The XMC_DE_EVENT_ENABLE methodis defined in the following table:

Index 2892 Data In rgData[0]—(number) DWORD, cookie (unique identifier)associated with the subscription. This value is returned to the clientwhen calling the subscription XMCAPI above. NOTE: using a cookie valueof zero (0) will enable/disable ALL items subscribed to the server.rgData[1]—(number) BOOL, TRUE to enable the subscription(s), FALSE todisable the subscription(s). Only enabled subscriptions actually fireevents. Data Out None.

This XMC_DE_EVENT_RECEIVE_DATA general method is called by the server(and implemented by the client) when each subscribed event fires and isdescribed in the following table:

Index 8045 Data In rgData[0]—(number) DWORD, subscription cookiecorresponding to the subscribed data item. rgData[1]—(number or string),data item value. rgData[2]—(OPTIONAL number) DWORD, data item time-stamp as a system time value. rgData[3]—(OPTIONAL string) LPSTR, dataitem ASCII text name. rgData[4]—(OPTIONAL number) DWORD, data itemunique cookie. NOTE: Since the last three items are optional, only thoseitems specified when configuring the data to receive are actually sent.If, for example, one or more data items are NOT requested, then theitems are returned in slots shifted up toward rgData[1]. For example ifonly the data item name is requested in addition to the default dataitems, the data returned would look like the following:rgData[0]—(number) DWORD, subscription cookie. rgData[1]—(number orstring), data item value. rgData[2]—(string) LPSTR, data item name. DataOut None.

The XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE general method is used toconfigure what type of data is returned on each event that is fired. Forexample in the server may be configured to send the minimal amount ofdata on each event (i.e. subscription cookie and data item value), orthe server may be requested to return more substantial data. TheXMC_DE_EVENT_RECEIVE_DATA_CONFIGURE method is defined in the followingtable:

Index 8044 Data In rgData[0]—(number) DWORD, flag describing the type ofdata to be returned on each event. The following flags are supported:XMC_DE_EVENT_DATA_FLAG_TIMESTAMP—requests that the time stamp recordedwhen reading the data is returned. XMC_DE_EVENT_DATA_FLAG_NAME—requeststhat the data items ASCII text name be returned.XMC_DE_EVENT_DATA_FLAG_DATA_COOKIE—requests that the unique data itemcookie corresponding to the read made for the data item be returned.NOTE: by default, the subscription cookie and data item value are alwaysreturned. Data Out None.

The XMC_DE_EVENT_SUBSCRIBE general method subscribes to a given dataitem activating the event interface when the subscription criteria aremet for the data item. All subscribing components use the IXMCDirectinterface to receive events received from the server for which they aresubscribed. The XMC_DE_EVENT_SUBSCRIBE method is described in thefollowing table:

Index 2890 Data rgData[0]—(number) DWORD, flags describing the initialIn state of the subscription. The following flags are supported:XMC_DE_EVENT_FLAG_ENABLED—subscription is immediately enabled uponsubscription. XMC_DE_EVENT_FLAG_DISABLED—subscription is disabled uponmaking the subscription. The Enable function must be called to enablethe subscription. rgData[1]—(number) DWORD, number of subscriptioncriteria rules. rgData[2 + (2*n)]—(number) DWORD, event condition typewhere the following types are supported:XMC_CNC_EVENTCONDITION_DATA_CHANGE—any data changes in the data typeabove will trigger the event. XMC_CNC_EVENTCONDITION_DATA_EQUALXMC_CNC_EVENTCONDITION_DATA_LESSTHANXMC_CNC_EVENTCONDITION_DATA_GREATERTHAN XMC_CNC_EVENTCONDITION_DATA_ANDXMC_CNC_EVENTCONDITION_DATA_OR Each of the conditions above are used ina combined manner. Where the logical condition (=, <, >) are applied foreach type respectively. For example, in an array that contains thefollowing items: rgData[2] = 4 (4 condition values) rgData[3] =XMC_CNC_EVENTCONDITION_EQUAL rgData[4] = 3.0 rgData[5] =XMC_CNC_EVENTCONDITION_LESSTHAN rgData[6] = 3.0 rgData[7] =XMC_CNC_EVENTCONDITION_OR rgData[8] = 1.0 rgData[9] =XMC_CNC_EVENTCONDITION_GREATHERTHAN rgData[10] = 5.0 the array would beevaluated using the following logic: If (DATA <= 3.0 OR DATA > 5.0) thenTrigger Event rgData[3 + (2*n)]—(number) double, the value for thecondition. See above. Data rgData[0]—(number) DWORD, cookie (uniqueidentifier) Out representing the subscription.

The XMC_DE_EVENT_UNSUBSCRIBE general method removes a previouslysubscribed data item from the subscription list maintained by the serverand is defined in the following table:

Index 2891 Data In rgData[0]—(number) DWORD, cookie (unique identifier)associated with the subscription. This value is returned to the clientwhen calling the subscription XMCAPI above. NOTE: using a cookie valueof zero (0) will unsubscribe ALL items subscribed to the server. DataOut None.

The XMC_DE_SYSTEM_INITIALIZEHW general method is used to initialize anyhardware systems associated with the component and is defined in thefollowing table:

Index 500 Data In None. Data Out None.

The XMC_DE_SYSTEM_SHUTDOWNHW general method is used to shutdown anyhardware systems associated with the component and is defined by thefollowing table:

Index 501 Data In None. Data Out None.

The following discussion will define which of the general methodsimplemented are implemented by particular components of the system 120.

The data collection component 140 implements the general methodsdescribed above as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMC_DE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

The following special notes apply to some of the general methodsimplemented by the data collection component 140.

The following component types are valid for theXMC_DE_SYSTEM_CONNECT_CMPNT method as implemented by the data collectioncomponent 140: the XMC_DE_CMPNT_TYPE_XMCDSRC, which specifies a datasource component 142.

The following component types are valid for theXMC_DE_SYSTEM_DISCONNECT_CMPNT method as implemented by the datacollection component 140: XMC_DE_CMPNT_TYPE_XMCDSRC, which specifies andata source component 142.

The data source component 142 implements the general methods describedabove as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMC_DE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

There are no special notes for the methods implemented by the datasource components 142.

The data store component 150 implements the general methods describedabove as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMC_DE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

The following special notes apply to each of the general methodsimplemented by the data store component 150.

The following component types are valid for theXMC_DE_SYSTEM_CONNECT_CMPNT method on the data store component 150:

-   -   XMC_DE_CMPNT_TYPE_XMCDCACHE, which specifies a data cache 152;    -   XMC_DE_CMPNT_TYPE_XMCDC, which specifies a data collection        component 140 that is connected with events; and    -   XMC_DE_CMPNT_TYPE_XMCDO, which specifies a data transport        component 162 that is connected with events.

The following component types are valid for theXMC_DE_SYSTEM_DISCONNECT_CMPNT method as implemented by the data storecomponent 150:

-   -   XMC_DE_CMPNT_TYPE_XMCDCACHE, which specifies a data cache 152;    -   XMC_DE_CMPNT_TYPE_XMCDC, which specifies a data collection        component 140 that is connected with events; and    -   XMC_DE_CMPNT_TYPE_XMCDO, which specifies an XMC data output        module 134 that is connected with events.

The data store component 150 implements the general methods describedabove as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMC_DE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

There are no special notes for the methods implemented by the data storecomponent 150.

The data output component 160 implements the general methods describedabove as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMC_DE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

The following special notes methods apply to the general methods asimplemented by the data output component 160.

The following component types are valid for theXMC_DE_SYSTEM_CONNECT_CMPNT as implemented by the data output component160:

-   -   XMC_DE_CMPNT_TYPE_XMCINFERENCE, which specifies an inference        engine component 166;    -   XMC_DE_CMPNT_TYPE_XMCDFORMAT, which specifies a data formatter        component 164; and    -   XMC_DE_CMPNT_TYPE_XMCDTRANSPORT, which specifies a data        transport component 162.

The following component types are valid for theXMC_DE_SYSTEM_DISCONNECT_CMPNT as implemented by the data outputcomponent 160:

-   -   XMC_DE_CMPNT_TYPE_XMCINFERENCE, which specifies an inference        engine component 166.    -   XMC_DE_CMPNT_TYPE_XMCDFORMAT, which specifies an data formatter        component 164.    -   XMC_DE_CMPNT_TYPE_XMCDTRANSPORT, which specifies an data        transport component 162.

The inference engine component 166 implements the general methodsdescribed above as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMC_DE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

There are no special notes for the methods implemented by the inferenceengine component 166.

The data formatter component 164 implements the general methodsdescribed above as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMCE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

There are no special notes for the methods implemented by the dataformatter component 164.

The data transport component 162 implements the general methodsdescribed above as indicated in the following table:

Not Method Implemented Implemented XMC_DE_BROWSE_GET_COUNT xXMC_DE_BROWSE_GET_ITEMS x XMC_DE_DATA_PROCESS xXMC_DE_DATA_PROCESS_CONFIGURE x XMC_DE_DATA_READ xXMC_DE_DATA_READ_CONFIGURE x XMC_DE_DATA_WRITE x XMC_DE_EVENT_ENABLE xXMC_DE_EVENT_RECEIVE_DATA x XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE xXMC_DE_EVENT_SUBSCRIBE x XMC_DE_EVENT_UNSUBSCRIBE xXMC_DE_SYSTEM_CONNECT_CMPNT x XMC_DE_SYSTEM_DISCONNECT_CMPNT xXMC_DE_SYSTEM_INITIALIZEHW x XMC_DE_SYSTEM_SHUTDOWNHW x

There are no special notes for the methods implemented by the datatransport component 162.

All methods exposed by each component in the example data routing system120 use a standard parameter set to describe data used to set and queryproperties as well as to invoke methods. The standard parameters are inthe following format:

pObj->InvokeMethod(LPXMC_PARAM_DATA rgData, DWORD dwCount);

Each element in the rgData array corresponds to a parameter, with thefirst element in the array corresponding to the first parameter.

The XMC_PARAM_DATA structure can contain either a numerical or a stringvalue and is defined as follows:

typedef struct tagXMC_PARAM_DATA {  LNG_PARAM_DATATYPE adt;  union  {  double df;   LPTSTR psz;  }; }XMC_PARAM_DATA;

The ‘adt’ member of the XMC_PARAM_DATA structure describes the datacontained within the XMC_PARAM_DATA structure. The values are describedbelow:

LNG_PARAM_DATATYPE Description LNG_ADT_NUMBER Use this value whenpassing a numerical value via the ‘adt’ member of the XMC_PARAM_DATAstructure. LNG_ADT_STAT_STRING Use this value when passing a staticstring value via the ‘psz’ member of the XMC_PARAM_DATA structure.Static strings do not need to be freed from memory. LNG_ADT_MEM_STRINGUse this value when passing a string value via the ‘psz’ member of theXMC_PARAM_DATA structure. LNG_ADT_MEM_STRING denotes that the stringmust be freed from memory during cleanup. LNG_ADT_NOP This value is usedto ignore items within the XMC_PARAM_DATA array. When specifies, thisparameter is not used.

When querying and setting boolean TRUE/FALSE values, any non-zero valueis considered TRUE, whereas a zero value is considered FALSE.

As described herein, the data routing system 120 is designed to collectdata from one or more data origins 122, perform some decision logic onthe data collected, and then send the data to one or more datadestinations 124 based on the outcome of the decision logic run on thedata inputs.

For example, data inputs may be data items describing the current stateof a machine tool, automobile or other machine as shown in FIG. 20. Thedecision logic would then use these data inputs to determine the overallhealth or efficiency of the machine. Data outputs would be used todescribe the machine's health or efficiency. This model thus operates asa data ‘router’, where data is routed from one or more input to one ormore output based on the decision logic run on the inputs. Typicallythis model is used to ‘cook-down’ a wide array of data inputs that arevery detailed in nature, to a more general set of data outputs thatdescribe the overall performance, state or behavior of the machine.

However, this overall model can easily run in the reverse where the datainput and output roles are reversed. In such an example, as generallyshown in FIG. 21 the inputs are general in nature and then decisionlogic is used to determine the specific detailed outputs necessary tocarry out a given behavior or action or to enter a given state.

For example using the latter model, a general input to a machine toolmay be something like ‘mill a pocket’ at a certain point. The decisionlogic in turn would then figure out all of the necessary tools,feedrate, spindlerate and moves necessary to create the pocket on thepart. Once determined, the decision logic would ‘output’ the values as aset of detailed output values such as the specific feedrate, thespecific spindlerate and the move profile to use. Each output would thenbe sent directly to the machine controller hardware that actually ranthe servo algorithms to move the tool and cut the part.

In another example, general inputs may be used to direct the path forwhich a car, airplane, ship or other mobile machine moved to a givendestination. For example, a general set of instructions would make upthe inputs such as follow road ‘x’ to intersection ‘y’, turn left atintersection ‘y’, drive to house ‘b’. The decision logic in this examplewould then be used to determine how to drive along road ‘x’ (making sureto track the right hand side of the road by following the yellow orwhite lines painted on the road), decision logic would determine whenthe intersection sought had been reached, how to negotiate the turn anddrive to house ‘b’. When making each of these decisions the decisionlogic system would more than likely require additional, more detailedinput from sensor systems. Each output could then take a more detailedform such as the speed that the car or other mobile should drive, andthe steering adjustments needed to track and follow the desired path onthe selected road.

II. Second Embodiment Command Distribution

The present invention relates to systems and methods for processingvarious types of commands transmitted between one or more commandsources and one or more command targets forming part of a larger commandsystem. The present invention is of particular significance when thecommand system is part of a motion control system, and that applicationwill be referred to on occasion below. As used herein, the term“command” refers to information that allows an operation to be executedon a command target.

The present invention may be implemented using any one or more of anumber of different system designs. A self contained system 520 of thepresent invention will be described below with reference to FIGS. 22-29.The self contained system 520 describes a command processor componentthat implements all command processing functionality within a singlecomponent. A modular design will be described with reference to FIGS.30-35. The modular design describes a command processor system made upof the command processor component and one or more command executioncomponents. The example self contained and modular designs are describedbelow with reference to a module interaction description and a set ofuse cases that describe how the modules interact with one another whencarrying out common operations.

In the present application, the term “module” is used to refer to abinary block of computer logic that contains functions, objects,components, ActiveX components, .NET source, HTML, XML and/or othercomputer code that can be executed in real-time or in script form.Several examples of a module include an executable EXE, a dynamic linklibrary DLL, an OLE component or set of components housed within a DLLor EXE, an ActiveX Control, an HTML or XML based Control, a VB scriptsource file, a Java Serverlet, Java Control, Java Object, .NET Package,etc. The term “component” as used herein refers to a logicalorganization of computer logic designed to perform a set of operations.Several examples of a component are an OLE Component, an ActiveXControl, an HTML or XML based Control, an HTML or XML based object, a.NET object, a Visual Basic based object, etc.

Referring now to FIG. 22 of the drawing, depicted therein at 520 is acommand processing system constructed in accordance with the principlesof a self contained system 520 of the present invention. The selfcontained system 520 comprises a command processor 522 implemented suchthat all command processing takes place within a single component. Theself contained system 520 may allow for faster command processing thancommand processing systems using alternative designs.

The command processor 522 is designed to run as an individualCOM+Component either in a stand alone manner under COM+. In the contextof a motion system, the command processor 522 may be designed to operateunder a Windows NT Service application for providing motion services(e.g., XMC Service). When run under COM+, the command processor 522 mayreceive commands in various forms, including SOAP (simple objectarchitecture protocol), Web Services, COM method calls, and bymonitoring a section of shared memory for command requests. Variousother command input methods may also employed.

The example command processing system 520 comprises the commandprocessor component 522, one or more command source components 530, andone or more command target components 532. The example command sources530 are each associated with a service client 534. The example commandprocessing system 520 further comprises a command service module 540 anda command service configuration and status module (configuration andstatus module) 542. In some situations, the command processing system520 may further comprise an event component 544.

The example command processor 522 receives, runs, and responds tocommands received through first and second areas 550 and 552 of sharedmemory in the system 520. The command processor may optionally run as aCOM+ component that services SOAP or other Web Service requests directlyor via COM+. The command processor 522 may optionally communicate withthe command target components 532 across a network, depending on theoverall system architecture. As used herein, the term “network” refersto a link between two or more computer systems and may be in the form ofa packet based network, a streaming based network, broadcast basednetwork, or peer-to-peer based network. Several network examples includea TCP/IP network, the Internet, an Intranet, a wireless network usingWiFi, a wireless network using radio waves and/or other light basedsignals, etc.

If the sent commands relate to a command operation that must run as aset of commands or not at all, the command processor 522 may employcommand ‘framing’ to ensure that the commands are run as a set. U.S.Pat. No. 6,480,896 to the present Applicant describes a system ofcommand framing in the context of a motion control system.

The example service clients 534 are thin service components associatedwith specific clients or types of clients that interface with the sharedmemory used to communicate command requests to the command processor522. Each service client 534 may also relay input to the commandprocessor 522 by receiving commands via some other protocol such asTCP/IP, SOAP Messaging, or the like that is transferred either locallyor across a network. Once received, the command is then converted intothe appropriate shared memory format to direct the command processor 522that a new command is ready for processing. Optionally the serviceclient 534 may communicate either locally or across a network usingOLE/COM interface methods of the command processor 522. This method istypically not as fast, but can allow for architectural flexibility.

In the context of a motion control system, the command sources 530 maybe formed by an application programming interface for motion systems 530a (e.g., XMC API), a system for processing data 530 b (e.g., XMC DataRouter), and/or other clients 530 c.

The command targets 532 are sets of components used to monitor devicesor machines. Each of the command targets 532 may be created forparticular device or machine or class of devices or machines. The terms“device” or “machine” as used herein refer to a physical asset used toperform a specified task. For example, a machine may be a CNC Mill usedto shape metal, a pick-n-place machine used to position parts on acircuit board, a robotic machine used to perform surgery, a medical datainput device used to collect the vitals from a human being (i.e. bloodglucose meter, asthma meter, etc), a gaming device used when playing agame, a robotic toy, an animatronics figure, a robotic machine used todeliver goods to a warehouse or to people, an automobile, truck or farmvehicle, a boat or ship that maneuvers in water, a airplane, jet,helicopter and/or spacecraft. Basically any self powered machine ordevice (mobile or not) that is either directly controlled by humans orautomatically controlled via a computer based system.

In the context of a motion control system, the command targets may beformed by a system of transmitting data to a motion system (data engine)534 a (e.g., XMCDE Data Engine system), a system for automating controlof a CNC motion system (CNC control system) 534 b (e.g., XMC CNCAutomation system), and/or a system for automating control of a GMCmotion system (GMC control system) 534 c (e.g., XMC GMC Automationsystem).

The configuration and status module 542 allows the user to configure theservice and gain status on how the application is running. The examplecommand service module 542 is a very thin Windows NT Service thatoptionally hosts the command processor 522, thereby allowing the commandprocessor to run even while the current user is not logged into thesystem.

The event component 544 sends event data received from one of the datasources formed by the target components 532 to one or more ‘listening’client components 534 associated with the command sources 530. The term“data” as used herein refers to any numeric or string data valuescollected from a target machine or device in an analog or digital formatthat is made compatible for computer systems. Examples of data typesthat represent data items include BIT, BYTE, WORD, DWORD, LONG, REAL,DOUBLE, FLOAT, STRING, ASCII STRING. Data may be collected from datasources using various methods such as reading register values on thedata source, reading shared memory provided by the data source, sendingcommands to the data source for which a data response is givencontaining the data requested, reading variables provided by the datasource, reading and writing to variables in a sequence necessary toproduce data values, querying data using a proprietary or standard dataprotocol, and/or calling a function provided by the target data source.

As shown in FIG. 22, the example command processor 522 comprises severalC++ objects and Windows NT threads that interact with one another toroute the commands received to the appropriate target components thatultimately carry out the specifics of the command requested. Inparticular, the example command processor 522 comprises a receptionthread 560 and one or more command threads 562.

The reception thread 560 is responsible for receiving commands placed inthe shared memory 552. The reception thread 560 continually scans theshared memory 552 for new commands triggered by the use of globalevents.

In the context of a motion control system, the command threads 562 areof two types, where a first command thread 562 a processes commandsassociated with the data engine 534 a and the second command thread 562b processes commands associated with the CNC motion system 534 b and theGMC motion system 534 c.

The following C++ objects are used to implement portions of the examplecommand processor 522.

The reception thread 560 comprises a ConfigMgr object 570, a DataMgrobject 572, and a QueueMgr object 574. The ConfigMgr object 570 accessesconfiguration information placed in the shared memory area 552 by theconfiguration and status module 542. The DataMgr 572 pulls commands fromthe memory area 550 shared with the service clients 534. The exampleQueueMgr object 574 manages one or more priority queues 576 servicingthe command threads 562.

The command threads 562 each comprise a StatusMgr object 580, a QueueMgrobject 582, and a CommandMgr object 584. The StatusMgr object 580 ismanages and updates the status area 552 of the shared memory used by theconfiguration and status module 542. The status information managed andupdated by the StatusMgr object 580 may be displayed to provide a userwith visual feedback on what the command threads 562 are actually doingat each point in time, as well as the number of elements in the commandqueues. The CommandMgr object 584 carries out each command by callingthe appropriate target components 532.

The interaction of the objects, threads and components forming thecommand processor 522 will now be described in several common use cases.The following use cases will be described below: Initialization, SystemStart, Command Processing (First Command Thread), Command Processing(Second Command Thread), Receiving Data, and Receiving Events. The stepsmaking up each use case are described in the order in which they occur.

Referring now to FIG. 23, the Initialization use case will first bedescribed. Initialization takes place when an application, such as thecommand services application 540, first starts up and loads the commandprocessor 522. During this process each of the threads are started andall C++ objects are initialized.

The following steps take place when initializing the command processor522. In step 1, the application hosting the command processor 522, suchas the XMC Windows NT Service or COM+ DLLHOST, starts up. In step 2, thehost application creates the component forming the command processor522. When first created, the component forming the command processor 522creates and starts the reception thread 560 in step 3. In step 4,ConfigMgr, DataMgr and QueueMgr objects 570, 572, and 574 used by thereception thread 560 are created and initialized.

In step 5, the second command thread 562 b is created and started. Instep 6, an instance of the StatusMgr object 580 b is created andinitialized. Once created, this component 580 b may be used to updatestatus information on the overall initialization process. In step 7,instances of the QueueMgr and CommandMgr objects 582 b and 584 b arecreated and initialized. In step 8, the CommandMgr object 584 b createsan instance of its associated target component 532 a.

In step 9, the command thread or threads 562 are created and started. Instep 10, an instance of the StatusMgr object 580 a is created andinitialized, allowing status information on the initialization progressof the command thread 562 a to be set. In step 11, an instance of theCommandMgr and QueueMgr objects 582 a and 584 a used by the thread 562 aare created and initialized.

At step 12, the CommandMgr creates an instance of the command targets532 b and 532 c. In the context of a motion control system, amulti-system configuration may optionally use separate threads toprocess CNC and GMC commands respectively.

After completing the initialization, the reception thread 560 placesitself in the ‘paused’ state so that it will not process any commandsuntil resumed. At this point the command processor 522 is initializedand ready to be started.

Once initialized, the reception thread 560 must be resumed from itspaused state prior to use of the system 520. No commands are processeduntil the reception thread 560 is resumed.

Referring now to FIG. 24, the following steps occur when starting thecommand processor 522. In step 1, the hosting command serviceapplication 540 calls a method on the command processor 522 component to‘start’ the command processing. In step 2, upon receiving the ‘start’call, the command processor 522 component resumes the reception thread560 causing the DataMgr object 572 to first query for any configurationchanges.

In step 3, the DataMgr object 572 queries the ConfigMgr object 574 forany configuration changes such as a new priority for the receptionthread 560, etc. The ConfigMgr object 570 queries the configurationshared memory for any settings. Once started as shown at step 4, theDataMgr object 572 resumes normal operation and continually checks fornew commands in the shared memory.

At this point all commands received are processed normally. Thefollowing sections describe how two of the main command types areprocessed; namely the example command threads 562 a and 562 b.

Referring first to FIG. 25, depicted therein is the processingimplemented by the second type of command thread 562 b. In general, allcommands associated with the command target 532 a are processed arerouted to the first command target 532 a. Examples of the commands sentto the command target 532 a are ‘Start’ or ‘Pause’ and these commandswill be referred to as first type commands.

The following steps occur when processing commands destined for thecommand target 532 a. In step 1, the command source 530 b calls theservice client 534 b requesting that a given first type command be run.As generally discussed above, some commands may be initiated by the hostitself, a user interface application, or even a protocol listener usedto convert and route command requests using the service client 534 b.

In step 2, the service client 534 b packages the command into an areawithin the shared memory area 550 specifically allocated for thatinstance of the service client 534 b. Within the command processor 522,the reception thread 560 is continually monitoring the shared memory 550for new commands as shown in step 3. Upon detecting a new command, theDataMgr object 572 extracts the command information from the sharedmemory area 550.

In step 4, the DataMgr object 572 passes the command information to theQueueMgr object 574. In step 5, the QueueMgr object 574 packages thecommand information into a queue command element and places the commandin the priority queue 576 b. The element may be placed at a location inthe queue based on the element's priority so that high priority commandsare processed sooner than low priority commands.

Within the command threads 562, the QueueMgr object 574 implicitlyreceives the queued command (i.e. it is the same queue accessed in thereception thread 560) as shown in step 6.

As shown in step 7, the CommandMgr object 584 b, which continuallychecks for new commands to run in the command thread 562 b, detects anew command and pulls it from the QueueMgr object 582 b. And finally instep 8, the CommandMgr object directs the command to the command targetcomponent 532 a, which carries out the requested command.

At this point the command is complete. However, the mechanism justdescribed does not allow notification back to the service client 534 bthat requested the command. This type of command is known as a‘broadcasted’ command, where the command is sent without sending backstatus on the results of the command carried out.

As shown in FIG. 26, the first command thread 562 a operates in a mannersimilar to that of the second command thread 562 b, except that commandsrouted through the first command thread 562 a are routed to one of thecommand targets 532 b and 532 c instead of the command target 532 a.

The following steps occur when processing commands destined for thecommand targets 532 b and 532 c.

In step 1, the service client 530 calls the Service Thin Clientrequesting to run a given first type command. Again, some commands maybe initiated by the host itself, a user interface application, or even aprotocol listener used to convert and route command requests using theservice client 534.

In step 2, the service client 534 a packages the command into the areawithin the shared memory area 550 specifically allocated for thatinstance of the service client 534 a.

Within the command processor 522, the reception thread 560 iscontinually monitoring the shared memory for new commands as shown instep 3. Upon detecting a new command, the DataMgr object 572 extractsthe command information from the shared memory.

As shown in step 4, the DataMgr object 572 passes the commandinformation to the QueueMgr object 574. At step 5, the QueueMgr object574 packages the command information into a queue command element andplaces the command in the priority queue 576 a. The element may beplaced at a location in the queue based on the elements priority so thathigh priority commands are processed sooner than low priority commands.

As shown at step 6, within the command thread 562 a, the QueueMgr object582 a implicitly receives the queued command (i.e. it is the same queueaccessed in the reception thread 560).

At step 7, the CommandMgr object 584 a, which continually checks for newcommands to run in the command thread 562 a, detects a new command andpulls it from the QueueMgr object 582 a.

And finally at step 8, the CommandMgr object 584 a directs the commandto the command target component 532 b and/or 532 c which carries out therequested command.

At this point the command is complete. Again, no notification is sentback to the service client 534 who requested the command. This examplecommand is known as a ‘broadcasted’ command where the command is sentwithout sending back status on the results of the command carried out.

While running the command processor 522, often it is important todisplay visual feedback on what the command processor 522 is actuallydoing. For example, the user may want to know whether the commandprocessor 522 is currently processing a command or how many commands arein the various command queues. The use case illustrated in FIG. 27illustrates how such user feedback can be attained while running thecommand processor 522.

The following steps occur when updating status while processing eachcommand.

In a step 1, the StatusMgr objects 580 a and 580 b collect statusinformation while each of the command threads 562 a and 562 b run. Allstatus information is saved to the status/configuration shared memoryarea 552.

In step 2, each application requesting status information reads theshared memory area 552 where the status information was placed.

The service client 534 that requested a command be run will want or needfeedback on the results of the command and in many cases data thatresults from running the command. The use case depicted in FIG. 28describes how feedback data may be returned to service clients 534.

The following steps occur when data and results are to be returned tothe service client 534.

In step 1, the service client 534 places the command into the sharedmemory area 550. Included with the command information is the name ofthe global event for which the service client 534 is waiting and whichshould be set by the command processor 522 upon completion of thecommand.

As shown in step 2, upon receiving the command, the DataMgr object 572extracts the command information from the shared memory area 550,including the name of the global event. At step 3, all commandinformation is passed to the QueueMgr object 574.

As shown at step 4, the QueueMgr object 574 packages the commandinformation into a command element that is then placed within theappropriate command priority queue 576 a and/or 576 b.

In step 5, the CommandMgr objects 584 within the command threads 562detect the command by querying the QueueMgr object 582 b. In step 6, theQueueMgr objects 582 return the command element or elements to theCommandMgr objects 584.

In step 7, the CommandMgr objects 584 run the command by delegating itto the appropriate command target 532. Upon completion of the command,the CommandMgr objects 584 update the shared memory 552 referenced bythe command element with the return result and any data returned by thecommand targets 532. Once all data is updated, the Command Mgr objects584 set the global event referenced by the command element, notifyingother components of the command processor 522 that execution of thecommand is complete.

In step 8, the event that the service client 534 is waiting on isreleased, thus freeing the service client 534 to continue with the dataplaced in the shared memory area 552 back in step 7. At this point thecommand processing for the command is complete.

In some cases, it is desirable for the service client 534 to receive‘unsolicited’ updates when certain events occur. FIG. 29 depicts thesituation in which the service client 534 receives updates upon theoccurrence of certain events. To receive events, the event component 544is accessible by the command client 534 and the command target 532. Inaddition, the service client 534 calls a command source 530 to‘subscribe’ to the event. Once subscribed, the event is fired to theservice client 534 when the event condition is met. The following stepsoccur when events are sent back to the service client 534.

In a first step, when the event condition is met, the component that isthe source of the event fires the event using the event component 544.In step 2, the event component 544 sends the ‘global’ event to allinstances of the event component 544. In step 3, the instance of theevent component 544 used by the service client 534 picks up the eventand calls an event handler on the service client 534. At this point theevent routing has completed.

Referring now to FIGS. 30-35, a modular design of a command processingsystem 620 of the present invention will now be described. The commandprocessing system 620 comprises command processor 622. The commandprocessing system 620 is more scaleable than the command processingsystem 520 described above in that it can support any type of commandwithout requiring any changes within the command processor 622.

In general, two component types interact with one another to processcommands received: the command processor 622 and a number of commandexecution components that will be described in further detail below. Aswith the system 520 described above, the system 620 transfers commandsbetween one or more command sources 630 and one or more command targets632. Each command source 630 is associated with a service client 634.The system 620 further comprises a command services module 640 and aconfiguration and status module 642. The system 620 further definesshared memory areas 650 and 652 a, 652 b, and 652 c.

To process commands, the command processor 622 routes each commandreceived to an appropriate command execution component 660 designated tohandle the type of command received.

Optionally, each of the command execution components 660 may be given aglobal priority that dictates how and when the command processor 622sends commands thereto. For example, FIG. 22 shows how three differenttypes of commands associated with three types of command targets 632 a,632 b, and 632 c may be supported. The design is specifically intendedto support many different kinds of commands, including commands not yetdefined by the command implementer of the command processor 622 and/orcommands defined by a third party. The design of the command processingsystem 620 thus allows for supporting many different types of commandswithout requiring changes in the overall command processor 522architecture. Another advantage of the design of the command processingsystem 620 is that this design allows for the deployment of new commandtypes to the field where the command processor 522 is already in use.

FIG. 31 is a slightly more detailed block diagram illustrating thecommand processor 622 and each command execution components 660.

The service client 634 functions as an interface between a shared memoryarea 650 and is used to communicate command requests to the commandprocessor 522. The service clients 634 may also be used to relay inputto the command processor 522 by receiving command via some otherprotocol such as TCP/IP, SOAP Messaging, etc., that is transferredeither locally or across a network. Once received, the command is thenconverted into the appropriate shared memory format to direct thecommand processor 522 that a new command is ready for processing.Optionally, the service client 634 may communicate either locally oracross a network using the OLE/COM interface methods of the componentsforming the command processor 622. This method is not as fast, but canallow for architectural flexibility.

The command processor component 622 receives and delegates each commandto the appropriate command execution component 660. The commandprocessor component 622 may also run optionally as a COM+ component thatservices SOAP or other Web Service requests, either directly or viaCOM+. Optionally, the command processor 622 may communicate with thecommand execution components 660 across a network.

Command execution components 660 are responsible for running the set ofcommands associated with the component. For example, individual commandexecution components 660 a, 660 b, and 660 c run commands that aredestined for the target component 632 a, 632 b, and 632 c, respectively.Optionally each individual command execution component 660 may run as aCOM+ component. Again, this may not optimize system speed, but canprovide desirable architectural flexibility.

The command execution components 660 may support using ArtificialIntelligence to break down generic commands into a set of more complexcommands used to carry out a task. As used herein, the term “artificialintelligence” refers to algorithms such as Neural Networks, GeneticAlgorithms, Fuzzy Logic, Expert Systems, combinations of all listed andother computer based decision making and pattern matching based systems.For example, a generic command may state to lift up a box. This commandwould then be broken down into the sequence of moves given the currentposition of a loader arm, necessary to pick up the box. The commandexecution component 660 may use Artificial Intelligence to do such abreakdown.

When communicating to the target component 632, the command executioncomponent 660 may do so either locally or across a network depending onthe overall system architecture. In the event that the commands sentcontain a critical operation that must run as a set of commands or notat all, the command processor may employ a form of command ‘framing’ asgenerally described above.

The example command service component 640 is a very thin Windows NTService that optionally hosts the command processor 622 thus allowingthe command processor to run even while the current user is not loggedinto the system. It should be noted that future versions may not needthis service as COM+ supports running components as a services. Sincethe command processor component 622 optionally supports COM+ it may alsobe run as a service in COM+.

The configuration and status module application 642 allows the user toconfigure the command processor 622 and various command executioncomponents 660 and obtain status on how each component is running.

The command targets 632 are or may be similar to the command targets 532described above, and the command targets 632 will not be described againherein beyond what is necessary for a complete understanding of thepresent invention.

Like the event component 544 described above, the event component 544;sends event data received from one of the various command targets 632 toone or more ‘listening’ service clients 634.

The details of the example command processor 622 will now be describedin detail. The example command processor 622 comprises several C++objects and a Windows NT thread that interact with one another to routethe commands received to the appropriate command execution component660.

The command process comprises a reception thread 670 that receivescommands placed in the shared memory area 650. The thread 670continually scans for new commands in the shared memory area 650. Thenew commands may be triggered by the use of global events.

The following example objects are C++ objects used to implement portionsof the command processor 622. A ConfigMgr object 672 pulls configurationinformation set in the shared memory area 650 by the configuration andstatus module 642. A DataMgr object 674 pulls commands stored by theservice client 634 in the shared memory area 650.

The command execution components will now be described in furtherdetail. Within the command execution component 660 several C++ objectsand a Windows NT thread interact with one another to run the commandsreceived.

Each command execution component 660 comprises a command thread 680. Thecommand threads 680 process commands destined for the command target 632that supports the command set associated with the command executioncomponent 660.

The following C++ objects are used to implement portions of the commandexecution component 660. A QueueMgr object 682 is responsible formanaging the various priority queues 684 servicing the command threads662.

A StatusMgr object 690 manages and updates the status area of the sharedmemory used by the configuration and status module 642. The statusinformation updated is used to allow visual feedback on the state of thecommand threads 562 as well as the number of elements in the commandqueues 684.

A CommandMgr object 692 carries out each command by calling theappropriate command targets 632.

The interaction of the objects, threads and components of the commandprocessing system 620 will now be described in reference to severalcommon use cases that take place on the command processor 622 duringnormal use. The following use cases will be described in detail below:Initialization, Command Processing, Receiving Events, and UpdatingStatus.

As shown in FIG. 32, when initializing the system, the following stepstake place. In step 1, before actually starting the initialization ofthe component, the user may optionally change the configuration of thecomponent using the configuration and status application 642, whichallows the user to configure the command processor 622 and/or allcommand execution components 660.

At step 2, when actually initializing the component, the command target632 (optionally a DLLHOST used when run as a COM+ server) creates thecommand processor component 622 and directs it to initialize itself.

At step 3, when created, the command processor 622 creates the receptionthread 560 and runs it. Within the reception thread 560 the ConfigMgr isinitialized at step 4. At step 5, the reception thread 560 initializesthe DataMgr object 674.

During its initialization, the DataMgr object 674 queries the ConfigMgrobject 672 for settings previously made by the user. For example, thelist of command execution components 660 installed is queried.

At step 7, the DataMgr object 674 then creates each command executioncomponent 660. When created, each command execution component 660creates its command thread 680 and starts running it at step 8. Withinthe command thread 680, the StatusMgr, QueueMgr and CommandMgr objectsare next initialized at step 9.

Upon completion of the command execution component 660 creation, at step10 the DataMgr object 674 within the reception thread 670 of the commandprocessor 622 sends a command to the command execution component 660directing the execution component 660 to initialize itself.

At step 11, the initialization command is received by the QueueMgrobject 692 in the command execution component 660. At step 12, theQueueMgr object 692 immediately places the command received into thecommand queue 684.

Within the command thread 680 of the command execution component 660, atstep 13 the CommandMgr object 694 queries the QueueMgr object 692 forany new commands and pulls the initialize command from the queue(previously placed in the queue in step 12 above).

The CommandMgr object 694 creates the appropriate command target 632 atstep 14, which runs the commands in the set associated with the specificcommand execution component 660. The command target 632 is also directedto initialize itself making it ready to process commands. Uponcompleting the initialization, the CommandMgr 694 unlocks the WindowsEvent associated with the command signifying that the command has beencompleted.

Referring back to the DataMgr object 674 within the reception thread 670in the command processor component 622, the DataMgr object 674 detectsthat the command has been completed and prepares to run more commands asshown at step 15.

The creation process, in which the command processor 622 and commandexecution components 660 are created, and the initialization process mayoptionally be separated. In this case, a specific command is firstcreated and then a specific ‘initialize’ command is then sent to thecommand processor directing it to prepare for receiving commands. Insuch a situation, the command processor 622 could block (wait until theinitialization command completed) and then return the results of theinitialization back to the configuration and status application 642 (orother host, such as DLLHOST, or a service client 634 using DLLHOST).

At this point the command processor 622 is running and ready to processcommands from the service client or clients 534.

Referring now to FIG. 33, the following steps take place when processinga given command. In step 1, the service client 634 software calls theservice client 634 directing it to run a given command.

In the step 2, the service client 634 then places the commandinformation into the shared memory area 650 designated by the commandprocessor 622 for the specific instance of the service client 634 (thisdesignation occurs when first creating the service client 634).Optionally, the service client 634 then waits for the command processor622 to signal that the event has completed. This signaling occurs eitherthrough information passed through the shared memory or with a globalsynchronization object, like a Windows NT Event object.

In step 3, the DataMgr object 674 of the reception thread 670 in thecommand processor 622 detects that a command is ready in the sharedmemory 650. The command information is extracted from the shared memory650.

In step 4, the DataMgr object 674 sends the command information to thecommand execution component 660.

Upon receiving the command information, the information is routed to theQueueMgr 692 which then places the command information into the commandqueue at step 5. Optionally, the command information is placed into thequeue 684 at a location specified by the command priority. For example,a high priority command may be placed at the beginning of the queue(i.e. pulled off the queue first) whereas a low priority command may beplaced at the end of the queue (i.e. pulled off the queue last).

In step 6, the CommandMgr 694 within the command thread 680 queries theQueueMgr 692 for any commands that may exist and, if one does exist,pulls the command from the front of the command queue 684.

The command is then run at step 7 by passing the command to the commandtarget 632 used to run the command. For example, second type commandmight be passed to the second command target 660 b.

At step 8, upon completion of the command, the CommandMgr 694 copies allreturn data into the shared memory 650 and then either togglesinformation in the shared memory 650 associated with the command orsignals a synchronization object, such as a Windows NT Event, to signifythat the command has completed.

In step 9, the service client 634 detects that the command has completedand picks up any return data placed in the shared memory 650 and returnsit to the command source 530.

At this point the command processing has completed.

Referring now to FIG. 34, the following steps occur when the serviceclient 634 receives unsolicited events from the command target 632.

When the event condition is met (the event condition being previouslyconfigured), the command target 632 fires the event using the eventcomponent 644 as shown in step 1. In step 2, the event component 644fires the event to all listening components including other instances ofthe event component 644. In step 3, the instance of the event component644 used by the service client 634 picks up the event and routes it tothe service client 634. The service client 634 then routes the eventinformation to the command source 630.

At this point the event processing is complete.

Referring now to FIG. 35, the following steps take place when updatingstatus information while the command processor component 622 and commandexecution component 660 process commands.

In step 1, during each loop within each command execution component 660status information is continuously updated using the StatusMgr object690. For example, the number of commands in the command queue 684 may beset in the status shared memory 652.

The configuration and status module 642 is then able to pick up theinformation from the shared memory and display it to the user, thusnotifying the user of the status of each command execution module 660(and optionally command processor 622) components. Optionally, aseparate thread may be used to monitor status information so as to notslow down or otherwise interfere with the command thread.

As generally described above, the example command processor 622 is amodular system made up of a set of components (i.e. each component isbased on a component technology such as OLE/COM from MicrosoftCorporation). Optionally, each component uses a separate ‘parallel’ActiveX component to implement all user interface aspects of the maincomponent. Each ActiveX component may be implemented either within themain component module or separately in its own module. Bundling eachobject within one module is not required as the objects may be locatedat any location (i.e. across a network, and so forth), but doing so mayoptimize communication between modules. The exact location of thecomponents in any given implementation of the present invention ismerely a logistical decision. Once components are built and deployed, itis difficult to update a single component if all components areimplemented within a single DLL or EXE module.

As shown in FIG. 36, the example components forming the commandprocessor 622 implement, at a minimum, a single interface: theIXMCDirect interface. Optionally, components that receive events fromother components can implement the IXMCDirectSink interface as well.

OLE Categories are used to determine how many components fall into acertain group of components. Currently the following categories areused:

-   -   command processor components—Typically there is only one command        processor component 622. However, in the event that the command        processor improves over time and has future more improved        versions, each new and improved version would fall into this        category of components.    -   command execution components—command execution components 660        are used to process a set of commands of a given type. For        example, the first command target 632 a, the second command        target 632 b, and the third command target 132 c represent        command types that may each have an associated command execution        component 660.

The IXMCDirect interface is used for most communications between allcomponents making up the command processor 622 Technology. The followingmethods make up this interface (as specified in the standard OLE/COM IDLformat):

-   -   GetProperty—This method is used to query a specific property        from the component implementing the interface.    -   SetProperty—This method is used to set a specific property from        the component implementing the interface.    -   InvokeMethod—This method is used to invoke a specific action on        the component implementing the interface. It should be noted        that an action can cause an event to occur, carry out a certain        operation, query a value and/or set a value within the component        implementing the method.

A more detailed description of each method implemented by the object isdescribed below.

IXMCDirect::GetProperty

Syntax HRESULT GetProperty( LPCTSTR pszPropName,   LPXMC_PARAM_DATArgData,   DWORD dwCount ); Parameters LPCTSTR pszPropName - string nameof the property to query. LPXMC_PARAM_DATA rgData - array ofXMC_PARAM_DATA types that specify each parameter corresponding to theproperty. For example, a certain property may be made up of a number ofelements - in this case an array of XMC_PARAM_DATA items is returned,one for each element making up the property. In most cases a property ismade up of a single element, thus a single element array is passed tothis method. For more information on the XMC_PARAM_DATA type, see below.DWORD dwCount - number of XMC_PARAM_DATA elements in the rgData array.Return HRESULT - NOERROR on success, or error code on Value failure.

This method is used to query the property corresponding to the propertyname ‘pszPropName’. Each component defines the properties that itsupports.

IXMCDirect::SetProperty

Syntax HRESULT SetProperty( LPCTSTR pszPropName,   LPXMC_PARAM_DATArgData,   DWORD dwCount ); Parameters LPCTSTR pszPropName - string nameof the property to set. LPXMC_PARAM_DATA rgData - array ofXMC_PARAM_DATA types that specify each parameter corresponding to theproperty. For example, a certain property may be made up of a number ofelements - in this case an array of XMC_PARAM_DATA items is returned,one for each element making up the property. In most cases a property ismade up of a single element, thus a single element array is passed tothis method. For more information on the XMC_PARAM_DATA type, see below.DWORD dwCount - number of XMC_PARAM_DATA elements in the rgData array.Return HRESULT - NOERROR on success, or error code on Value failure.

This method is used to set a property in the component corresponding tothe ‘pszPropName’ property. For the set of properties supported by thecomponent, see the specific component description.

IXMCDirect::InvokeMethod

Syntax HRESULT InvokeMethod( DWORD dwMethodIdx,   LPXMC_PARAM_DATArgData,   DWORD dwCount ); Parameters DWORD dwMethodIdx - numbercorresponding to the specific method to invoke. For more information onthe method indexes available, see the set of namespaces defined for thecomponent. LPXMC_PARAM_DATA rgData [optional] - array of XMC_PARAM_DATAtypes that specify each parameter for the method called. For moreinformation on the XMC_PARAM_DATA type, see below. NOTE: if noparameters exist for the method called, a value of NULL must be passedin. DWORD dwCount [optional] - number of XMC_PARAM_DATA elements in thergData array. NOTE: if no parameters exist for the method called, avalue of 0 (zero) must be passed in for this parameter. LPXMC_PARAM_DATArgData [optional] - namespace associated with the instance of the customextension module added. Return HRESULT - NOERROR on success, or errorcode on Value failure.

This method is used to call a specific method implemented by thecomponent. For more information on the methods supported, see thedescription of the specific component.

The IXMCDirectSink interface is an event reception point on which onecomponent can send event data to another. The component implementingthis interface is the event receiver. The event source calls theinterface passing to it event data.

The IXMCDirectSink interface is made up of the following functions.

-   -   OnEvent—This method is called by the event source when an event        occurs (i.e. the conditions defining the event are met).    -   OnError—This method is called by the event source when an error        occurs.

A more detailed description of each method implemented by the object isdescribed below.

IXMCDirectSink::OnEvent

Syntax HRESULT OnEvent( long IApiIdx,   SAFEARRAY** ppSA ); Parameterslong IApiIdx - index associated with the event type . . . SAFEARRAY**ppSA - pointer to a pointer to a SAFEARRAY containing an array ofXMC_PARAM_DATA structures. For more information on the XMC_PARAM_DATAtype, see below. Return HRESULT - NOERROR on success, or error code onValue failure. Notes The SAFEARRAY passed to this method contains anarray of XMC_PARAM_DATA structures. This array has the followingentries: rgData[0] LONG IConnectionCookie - unique cookie associatedwith this connection to the XMC Motion Server (returned when calling theInitializeHardware method on the XMC Motion Server). rgData[1] DWORDdwSubscriptionCookie - unique cookie associated with the subscriptionfor which this event has fired. This cookie is returned when making thesubscription. rgData[2] DWORD dwDataCookie - unique cookie associatedwith the specific data change that triggered the event. This cookie isgenerated within the XMC Motion Server. rgData[3] LPCTSTR pszItemName -name of the item or variable for which the subscription is associated.rgData[4] double dfTimeStamp - number of milliseconds passed from thetime that the event pump, implemented by the XMC Motion Server, wasfirst started. rgData[5] DWORD dwDataCount - number of data valuesassociated with the event (i.e. the number of structure elements thatfollow). rgData[6 + Number or String - actual data values associatedwith the n] event.

This method is called by the event source and passed the event data in aSAFEARRAY form for easy marshalling across process boundaries.

IXMCDirectSink::OnError

Syntax HRESULT OnError( long IApiIdx,   SAFEARRAY** ppSA ); Parameterslong IApiIdx - index associated with the event type . . . SAFEARRAY**ppSA - pointer to a pointer to a SAFEARRAY containing an array ofXMC_PARAM_DATA structures. For more information on the XMC_PARAM_DATAtype, see below. Return HRESULT - NOERROR on success, or error code onValue failure. Notes The SAFEARRAY passed to this method contains anarray of XMC_PARAM_DATA structures. This array has the followingentries: rgData[0] LONG IConnectionCookie - unique cookie associatedwith this connection to the XMC Motion Server (returned when calling theInitializeHardware method on the XMC Motion Server). rgData[1] DWORDdwSubscriptionCookie - unique cookie associated with the subscriptionfor which this event has fired. This cookie is returned when making thesubscription. rgData[2] DWORD dwDataCookie - unique cookie associatedwith the specific data change that triggered the event. This cookie isgenerated within the XMC Motion Server. rgData[3] LPCTSTR pszItemName -name of the item or variable for which the subscription is associated.rgData[4] double dfTimeStamp - number of milliseconds passed from thetime that the event pump, implemented by the XMC Motion Server, wasfirst started. rgData[5] HRESULT hrResult - result code of the error forwhich the event is associated. rgData[6] LPCTSTR pszError - stringdescription of the error. rgData[7] LONG ISrcError - error codedescribing the source of the error. For example, this may be an errorcode returned by a computer controlled piece of hardware. rgData[8]LPCTSTR pszSrcError - string describing the source error.

This method is called by the event source when an error occurs andpassed the event error data in a SAFEARRAY form for easy marshallingacross process boundaries.

The methods supported by each component making up the system 620 willnow be described. In particular, the methods supported by the majorityof the components will be described below. For the specific list ofmethods supported by each component, see the section describing eachcomponent.

XMC_CP_SYSTEM_CONNECT_CMPNT

Index 8000 Data In rgData[0] - (number) DWORD, type of component. Thetype of component is a value that is server specific. For component typeinformation, see the description for this method under each server'sdescription. rgData[1] - (string) LPTSTR, component class id as an ASCIIstring. Data Out None.

This method is used to connect one server to another so that they mayinteract with one another.

XMC_CP_SYSTEM_DISCONNECT_CMPNT

Index 8001 Data In rgData[0] - (number) DWORD, type of component. Thetype of component is a value that is server specific. For component typeinformation, see the description for this method under each server'sdescription. rgData[1] - (string) LPTSTR, component class id as an ASCIIstring. Data Out None.

This method is used to disconnect one server to another so that theystop interacting with one another.

XMC_CP_PROCESS_START

Index 8500 Data In None. Data Out None.

This method is called to start the command processor technology makingit ready to process commands.

XMC_CP_PROCESS_ENABLE

Index 8501 Data In rgData[0] - (number) BOOL - TRUE enables the commandprocessor, FALSE disables it. The command processor only processescommands when it is enabled. Data Out None.

This method is used to configure what type of data is returned whenprocessing a given data item. For example in the server may beconfigured to return the minimal amount of data on each read (i.e. justthe data item value), or the server may be requested to return moresubstantial data.

XMC_CP_PROCESS_STOP

Index 8061 Data In None. Data Out None.

This method is called to shut-down the command processor.

XMC_DE_EVENT_ENABLE

Index 2892 Data In rgData[0] - (number) DWORD, cookie (uniqueidentifier) associated with the subscription. This value is returned tothe service client 34 when calling the subscription COMMAND SOURCE #1above. NOTE: using a cookie value of zero (0) will enable/disable ALLitems subscribed to the server. rgData[1] - (number) BOOL, TRUE toenable the subscription(s), FALSE to disable the subscription(s). Onlyenabled subscriptions actually fire events. Data Out None.

This method enables/disables a previously subscribed data item in thesubscription list maintained by the server. Only enabled subscriptionsactually fire.

XMC_DE_EVENT_RECEIVE_DATA

Index 8045 Data In rgData[0] - (number) DWORD, subscription cookiecorresponding to the subscribed data item. rgData[1] - (number orstring), data item value. rgData[2] - (OPTIONAL number) DWORD, data itemtime- stamp as a system time value. rgData[3] - (OPTIONAL string) LPSTR,data item ASCII text name. rgData[4] - (OPTIONAL number) DWORD, dataitem unique cookie. NOTE: Since the last three items are optional, onlythose items specified when configuring the data to receive are actuallysent. If, for example, one or more data items are NOT requested, thenthe items are returned in slots shifted up toward rgData[1]. For exampleif only the data item name is requested in addition to the default dataitems, the data returned would look like the following: rgData[0] -(number) DWORD, subscription cookie. rgData[1] - (number or string),data item value. rgData[2] - (string) LPSTR, data item name. Data OutNone.

This method is called by the server (and implemented by the serviceclient 534) when each subscribed event fires.

XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE

Index 8044 Data In rgData[0] - (number) DWORD, flag describing the typeof data to be returned on each event. The following flags are supported:XMC_DE_EVENT_DATA_FLAG_TIMESTAMP - requests that the time stamp recordedwhen reading the data is returned. XMC_DE_EVENT_DATA_FLAG_NAME -requests that the data items ASCII text name be returned.XMC_DE_EVENT_DATA_FLAG_DATA_COOKIE - requests that the unique data itemcookie corresponding to the read made for the data item be returned.NOTE: by default, the subscription cookie and data item value are alwaysreturned. Data Out None.

This method is used to configure what type of data is returned on eachevent that is fired. For example in the server may be configured to sendthe minimal amount of data on each event (i.e. subscription cookie anddata item value), or the server may be requested to return moresubstantial data.

XMC_DE_EVENT_SUBSCRIBE

Index 2890 Data In rgData[0] - (number) DWORD, flags describing theinitial state of the subscription. The following flags are supported:XMC_DE_EVENT_FLAG_ENABLED - subscription is immediately enabled uponsubscription. XMC_DE_EVENT_FLAG_DISABLED - subscription is disabled uponmaking the subscription. The Enable function must be called to enablethe subscription. rgData[1] - (number) DWORD, number of subscriptioncriteria rules. rgData[2 + (2 * n)] - (number) DWORD, event conditiontype where the following types are supported:XMC_CNC_EVENTCONDITION_DATA_CHANGE - any data changes in the data typeabove will trigger the event. XMC_CNC_EVENTCONDITION_DATA_EQUALXMC_CNC_EVENTCONDITION_DATA_LESSTHAN XMC_CNC_EVENT-CONDITION_DATA_GREATERTHAN XMC_CNC_EVENTCONDITION_DATA_ANDXMC_CNC_EVENTCONDITION_DATA_OR Each of the conditions above are used ina combined manner. Where the logical condition (=, <, >) are applied foreach type respectively. For example, in an array that contains thefollowing items: rgData[2] = 4 (4 condition values) rgData[3] =XMC_CNC_EVENTCONDITION_EQUAL rgData[4] = 3.0 rgData[5] =XMC_CNC_EVENTCONDITION_LESSTHAN rgData[6] = 3.0 rgData[7] =XMC_CNC_EVENTCONDITION_OR rgData[8] = 1.0 rgData[9] =XMC_CNC_EVENTCONDITION_GREATHERTHAN rgData[10] = 5.0 the array would beevaluated using the following logic: If (DATA <= 3.0 OR DATA > 5.0) thenTrigger Event rgData[3 + (2 * n)] - (number) double, the value for thecondition. See above. Data Out rgData[0] - (number) DWORD, cookie(unique identifier) representing the subscription.

This method subscribes to a given data item activating the eventinterface when the subscription criteria are met for the data item. Inthe example system 620, all unsubscribing components must use theIXMCDirect interface to receive events received from the server forwhich they are subscribed.

XMC_DE_EVENT_UNSUBSCRIBE

Index 2891 Data In rgData[0] - (number) DWORD, cookie (uniqueidentifier) associated with the subscription. This value is returned tothe service client 34 when calling the subscription COMMAND SOURCE #1above. NOTE: using a cookie value of zero (0) will unsubscribe ALL itemssubscribed to the server. Data Out None.

This method removes a previously subscribed data item from thesubscription list maintained by the server.

XMC_DE_SYSTEM_INITIALIZEHW

Index 500 Data In None. Data Out None.

This method is used to initialize any hardware systems associated withthe component.

XMC_DE_SYSTEM_SHUTDOWNHW

Index 501 Data In None. Data Out None.

This method is used to shut down any hardware systems associated withthe component.

The command processor component 622 implements the following generalmethods listed above.

Not Method Implemented Implemented XMC_CP_PROCESS_START X xXMC_CP_PROCESS_ENABLE X x XMC_CP_PROCESS_STOP X XMC_DE_EVENT_ENABLE XXMC_DE_EVENT_RECEIVE_DATA X XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE XXMC_DE_EVENT_SUBSCRIBE X XMC_DE_EVENT_UNSUBSCRIBE XXMC_DE_SYSTEM_CONNECT_CMPNT X XMC_DE_SYSTEM_DISCONNECT_CMPNT XXMC_DE_SYSTEM_INITIALIZEHW X XMC_DE_SYSTEM_SHUTDOWNHW X

There are no special notes for the methods that this componentimplements.

The command execution components 660 implement the following generalmethods listed in the general component methods section above.

Not Method Implemented Implemented XMC_CP_PROCESS_START XXMC_CP_PROCESS_ENABLE X XMC_CP_PROCESS_STOP X XMC_DE_EVENT_ENABLE XXMC_DE_EVENT_RECEIVE_DATA X XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE XXMC_DE_EVENT_SUBSCRIBE X XMC_DE_EVENT_UNSUBSCRIBE XXMC_DE_SYSTEM_CONNECT_CMPNT X XMC_DE_SYSTEM_DISCONNECT_CMPNT XXMC_DE_SYSTEM_INITIALIZEHW X XMC_DE_SYSTEM_SHUTDOWNHW X

There are no special notes for the methods that this componentimplements.

The definitions of all special types used by the methods and propertiesof each component making up the command processor system 622 will now bedescribed.

XMC_PARAM_DATA Structure

All methods exposed by each component in the example system 622 use astandard parameters set to describe data used to set and queryproperties as well as invoke methods. The standard parameters are in thefollowing format:

pObj->InvokeMethod(LPXMC_PARAM_DATA rgData, DWORD dwCount);

Each element in the rgData array corresponds to a parameter, with thefirst element in the array corresponding to the first parameter.

The XMC_PARAM_DATA structure can contain either a numerical or a stringvalue and is defined as follows:

typedef struct tagXMC_PARAM_DATA {  LNG_PARAM_DATATYPE adt;  union  {  double df;   LPTSTR psz;  }; }XMC_PARAM_DATA;

The ‘adt’ member of the XMC_PARAM_DATA structure describes the datacontained within the XMC_PARAM_DATA structure. The values are describedbelow:

LNG_PARAM_DATATYPE Description LNG_ADT_NUMBER Use this value whenpassing a numerical value via the ‘adt’ member of the XMC_PARAM_DATAstructure. LNG_ADT_STAT_STRING Use this value when passing a staticstring value via the ‘psz’ member of the XMC_PARAM_DATA structure.Static strings do not need to be freed from memory. LNG_ADT_MEM_STRINGUse this value when passing a string value via the ‘psz’ member of theXMC_PARAM_DATA structure. LNG_ADT_MEM_STRING denotes that the stringmust be freed from memory during cleanup. LNG_ADT_NOP This value is usedto ignore items within the XMC_PARAM_DATA array. When specifies, thisparameter is not used.

When querying and setting boolean TRUE/FALSE values, any non-zero valueis considered TRUE, whereas a zero value is considered FALSE.

The command processor 622 of the present invention may be used on morethan just motion based devices and machines, although the presentinvention is of particular significance in that environment. Theprinciples of the present invention may also be used to send commands tomedical devices where each command directs the medical device to carryout a set of operations. It may also be used to send commands to farmingequipment, heavy machinery such as tractors, excavators, bulldozers,cranes, semi-trucks, automobiles, drilling equipment, water craft suchas submersibles, boats and ships, airplanes (including jets),spacecraft, satellites, and any other kind of mobile device or machinethat moves on land, water or within the air or space.

The technology implemented by the present invention may be used to sendcommands in the following environments:

-   -   office equipment such as printers, fax machines, telephone        systems, internet routers, internet firewalls and security        cameras and general security systems.    -   general consumer devices such as home entertainment systems,        televisions, microwaves, ovens, refrigerators, washers and        driers, vacuums, hand held music systems, personal digital        assistants, toys, musical instruments, etc.    -   yard items such as lawn mowers, yard care devices, snow blowers,        air blowers, edger's, etc.    -   military equipment such as drone airplanes, drone tanks, drone        land mobiles, drone boats, tanks, ships, jets and any other        mobile or stationary devices used on land, sea or in the air or        space.    -   various types of factory equipment that may or may not use        motion to carry out its task, such as i/o devices, analog        devices, CNC machines, General Motion machines, FMS machines,        measuring systems, etc.    -   animatronics devices such as robot dogs, robotic mannequins,        robotic helpers, or other robotic human-like or robotic animal        like devices.

The term “command data” as used herein refer to any numeric or stringdata values used to describe the command and parameters describing howto perform the command. For example, BIT, BYTE, WORD, DWORD, LONG, REAL,DOUBLE, FLOAT, STRING, ASCII STRING are a few command data types thatrepresent commands and/or command parameters. Command data mayeventually be sent to the command target by writing register values onthe command target, writing to shared memory provided by the commandtarget, sending commands to the command target for which a data responseis given containing the data requested, writing to variables provided bythe command target, reading and writing to variables in a sequencenecessary to carry out the commanded operation, using a proprietary orstandard data protocol, calling a function provided by the commandtarget, etc.

III. Third Embodiment Database Distribution

Referring now to FIGS. 37-43 of the drawing, depicted therein is anexample data routing system 720 constructed in accordance with, andembodying, the principles of the present invention. The example datarouting system 720 comprises a data engine 722, a data source 724, adata transport 726, and a protocol server 728.

The example data routing system 720 is designed to operate, in a firstimplementation, in conjunction with a machine platform 730, a databaseserver platform 732, and an event system 734 as shown in FIG. 37. Thedata example routing system 720 also operates, in a secondimplementation, in conjunction with a database client 736 and a commandprocessor 738 as shown in FIG. 43.

The data engine 722 is configured to manage the overall data routingsystem 720. The data source 724 forms an input to the data router system720 by providing a link to the data source such as the machine platform730. The example data source 724 provides this link using OLE Automationinterfaces. The data transport 726 forms an output of the data routersystem 720 that sends data to a data target such as the database serverplatform 732. The protocol server 728 receives events from the eventsystem 734 each time a record is entered into the database serverplatform 732.

The example machine platform 730 is connected to, or incorporates, atarget machine and is configured to unify the data of and access to thetarget machine. Within the example machine platform 730 is an eventthread pool 740 is used to send data to outbound targets such as datasource 724 of the data routing system 720. The example machine platform730 also incorporate an optional motion event component 742 such as thatdescribed in the Applicants' U.S. Pat. No. 5,691,897. The contents ofthe '897 patent is included herein by reference.

The example server platform 732 incorporates or is formed by a MicrosoftSQL server that defines a data router database 750. The data routerdatabase 750 is configured with a number of tables including a ‘States’table that contains all state updates made by the data router system 720as will be described in further detail herein. The ‘States’ table alsoincludes an INSERT trigger that fires each time a record is insertedinto the table.

The event system 734 comprises a database event 760 and a system event762. In the example data router database 750, when the INSERT triggerfires, the database event 760 is called and thus notified of the newlyinserted data. The example database event 760 is the XMCSQLEVT event,which is a Com+ event as implemented by the example database 750.

The database event 760 uses the system event 762 to notify any outsideapplication, such as the protocol server 728, of data updates made tothe ‘States’ table within the data router database 750. In particular,the example protocol server 728 receives, through the event system 762,events from the database event 760 each time a record is inserted intothe ‘States’ table. Upon receiving each event, the protocol server 728updates an internal cache for the data item.

When outside clients of the protocol server 728 read the data item, thedata from the cache is served up to the client. In addition, the exampleprotocol server 728 may also browse the data router database 750 for allassets, states, and sub-states to create an address space that reflectsthe data within the tables defined by the data router database 750.

The protocol server 528 depicted in FIGS. 37-43 is presented simply asan illustration of one example of how the data routing system 720 may beconfigured. The example protocol server 528 relies on tables andtriggers from within data router database and need not configured basedon any upstream software that places data within those tables.

Turning now to FIGS. 38-43 of the drawing, depicted therein are a numberof use cases illustrating sequences of steps that are performed by oneor more of the modules making up the data routing system 720 and themachine platform 730, server platform 732, event system 734, databaseclient 736, and/or command processor 738. In particular, the followinguse cases are described: initialization of the overall system; how thedata items provided by the server are browsed; how the data updates aremade on the server; how clients of the server read and receive data; andan alternative configuration of the data routing system 720 that usesdata router database 750 to command a motion system associated with themachine platform 730 to perform one or more actions.

Referring initially to FIGS. 38 and 39 of the drawing, an example of theprocess of initializing the data routing system 720 is depicted therein.The initialization process is a two step process. First the data routerdatabase 750 is initialized as shown in FIG. 38. Second, protocol server728 is initialized as shown in FIG. 39.

In the example data routing system 720, the data router database 750 isinitialized before the protocol server 728 is initialized.

The following steps take place when initializing the example data routerdatabase 750. First, a software application portion of the data routingsystem 720 is used to initialize the database by configuring the datatransport 726 and directing the data transport 726 to initialize thedata router database 750 by using, for example, an XML data file thatdescribes all assets, states and sub-states that are to be loaded intothe database. Second, during this process data transport 726 creates alltables and creates an INSERT Trigger on the ‘States’ table that callsthe XMC SQL Event Class each time a record is inserted into the ‘States’table. When the data router database 750 is initialized, the database750 is ready for use by the protocol server 728.

The protocol server 728 is initialized each time a client applicationcreates an instance of the server 728 to use. FIG. 39 illustrates oneexample of the process of initializing the protocol server 728. Thefollowing steps are performed when the protocol server 728 isinitialized. First, the protocol server 728 browses the ‘Assets’ tableto receive a list of all assets as well as the ‘StateTagsView’ toreceive a list of all states and their sub-states. The protocol server728 uses the list of all assets and list of all states and theirsub-states to build the address space of the protocol server 728.

Second, the protocol server 728 subscribes to the event class associatedwith the database event 760 defined by the event system 734. The exampleprotocol server 728 subscribes to the late bound XMC SQL Event Classprovided by the COM+ Event System. At this point the protocol server 728is ready to use. In the example described herein, an internal item tree,used when browsing items, is built during the first step of the processof initializing the protocol server 728.

Referring now to FIG. 40 of the drawing, a browsing process implementedby the data routing system 720 will now be described. Browsing is theprocess if viewing (and walking) the list of items exposed by theprotocol server 728. More specifically, browsing is the process ofeither visually selecting items from a tree of items browsed, orprogrammatically selecting one or more items from the tree. In addition,browsing may involve walking the tree items. For example, when searchingfor a given item, a program may iteratively look at each item while itdetermines if each is the item the program is looking for.

The example item tree used by the process illustrated in FIG. 40 is madeup of asset names at the top level, states at the next level, andsub-states at the last ‘leaf’ level. An example of the item tree is setforth below:

Root | |--Asset  |  |-- State   |   |-- Sub-State (this is the item)

During the browsing process, each of the elements making up the itemtree are retrieved from the data router database 750. In the examplesystem depicted in FIG. 40, the Assets are loaded from the ‘Assets’table, and the State and Sub-States are retrieved from the‘StateTagsView’ view.

The following step takes place when browsing items exposed by theprotocol server 728. The protocol server 728 walks the browse tree thatwas previously built when initializing the server by querying the Assetstable and StateTagsView view. Browsing the items allows an applicationto select which data items are to be monitored.

Referring now to FIG. 41 of the drawing, depicted therein is the dataupdate process. Data updates are received by the protocol server 528each time a record is inserted into the ‘States’ table of the datarouter database 750. In the example depicted in FIG. 41, upon thecompletion of each insert, the database 750 calls the database event 760(XMC SQL Event Class), which routes an event to the protocol serverprotocol server (XMC SQL OPC Server) via the system event 762 (COM+Event System).

The following steps occur when data updates are processed by the system.First, a data event is fired by one of the threads in the event threadpool provided by the motion event component 742 of the machine platform720. The motion event component 742 may be as described in copendingU.S. patent application Ser. Nos. 11/067,327 and 11/375,502. Thecontents of the '327 and '502 applications are incorporated herein byreference.

Second, the data source 724 receives the event and passes theinformation up to the data engine 722. Third, the data engine 722 runsthe data associated with the received event through a set of rules thatdetermine whether the data should be sent to the data transport 726. Inthe example data engine 722, if the rule determines that the data shouldsent, and an ‘identity’ type is used in the rule, the raw data is sentto the data transport 726. Using an identity type in a data router ruleset directs the data router to pass the actual data along with each rulethat fires.

Third, upon receiving the data, the data transport 726 inserts the data(along with the raw data) into the ‘States’ table and an ‘ExtraInfo’tables within the data router database 750. Upon completing the INSERToperation into the States table, the data router database then fires andInsert Trigger (OnInsertTrigger). In this particular implementation,Insert Triggers use Microsoft SQL Server and may not run correctly fromwithin the MSDE environment.

Fifth, the OnInsertTrigger calls the database event 760 (XMCSQLEVT COM+Event Class) within its stored procedure. The Asset, State, Sub-State,raw data and time-stamp of the INSERT trigger are all passed to theevent class.

Sixth, the event system 734 (COM+) routes the database event 760 (XMCSQL Event Class event) to the protocol server 728, which has alreadysubscribed to such events during its initialization process. Uponreceiving the event, the protocol server 728 stores the data received inits data cache for the item. It should be noted that data updates do notdirectly trigger updating clients of the protocol server 728, butinstead continually refresh its internal data cache of data items.

Turning now to FIG. 42 of the drawing, the process of reading data willbe described in further detail. The data reading process is carried outby each client. The client can read data Data directly or using updatesvia an event that fires periodically. In either case, data istransferred during this process from the protocol server 728 to theclient application. As shown in FIG. 42, when reading data, data isserved to the client application either via a periodic update, when datachanges, or when the client directly asks for the data.

Referring now to FIG. 43 of the drawing, the process of commanding amotion system using the data routing system 720 will now be described.The implementation of the invention described with reference to FIGS.38-42 describe the process of reading data from a motion system.However, the architecture of the data routing system 720 of the presentinvention may be used to command a motion system to perform one or moreactions.

As described above, the data routing system 720 is used in conjunctionwith the client application 736 and command processor 738 in FIG. 43.The client application 736 is a software application, component module,script, web page, or the like that determines a series of motion stepsto be carried out. The command processor 738 generates commands thatcarry out the series of motion step defined by the client application736. The command processor 738 may be implemented using the commandprocessor described in U.S. patent application Ser. No. 10/991,905,which is included by reference herein in its entirety.

To process command via database input, the following steps occur. Firstthe database client inserts commands into the Command table found withinthe data router database 750. Second, when inserted, all insertedcommand information (including the command and its parameters, andoptionally the return data routing location such as a table where returndata is to be placed) is sent to the XMCSQLEVT COM+ Event Class to fire.Third, the COM+ Event System fires the late coupled events (LCE) to anysubscribers that may exist.

Fourth, the XMCSQLEVT COM+ Event Class supports the IXMCaSQLEventinterface, which is called on all subscribers to the event class eachtime the event fires. Upon receiving the events, the command processor738, processes the events by sending the commands to the target motionsystem(s) designated to receive the commands. Note, there are severalway t the command processor may deliver the commands to target motionsystems: The command processor may send the commands to motion systemsspecified in the event parameters, or the command system may send thecommands to motion systems pre-configured in the command processor toreceive specific (or all) events, or the command processor may broadcastthe events to all motion systems connected to it.

Sixth, upon receiving the command(s), each motion system carries out thecommands using the command+all of its parameter data. If data is to bereturned, the return data is sent back to the command processor who thenin-turn routes the data back to the routing target. Optionally, the datarouter 720 may be used to return information as well.

The system described in this document is a very modular system made upof a set of components. For example, each component may be based on acomponent technology such as OLE/COM from Microsoft Corporation.Detailed descriptions of the interfaces of the example components usedfor communication between the various pieces making up the system areset forth below.

Upon receiving an insert instruction into a designated table (i.e. theStates table in the data router database 736 (or a Command table in thecommand processor database) a pre-configured event trigger is fired bythe data router database 750 that sends the inserted data to thedatabase event 760 (XMCSQLEVT module). In the example described herein,the event trigger calls the module's IXMCaSQLEvent interface. Theexample IXMCaSQLEvent interface will be described in further detailbelow.

The IXMCaSQLEvent interface is used by server platform 732 to send eventinformation to any subscribers of the XMC SQL Event Class.

Method Summary

The IXMCaSQLEvent interface is made up of the following functions.

-   -   OnInsertTrigger—This method is used to send the data to each        event subscriber as a single string.    -   OnInsertTriggerEx—This method is used to send data to each event        subscriber as a set of strings.        A more detailed description of each method implemented by the        object is described below.

IXMCaSQLEvent::OnInsertTrigger

Syntax HRESULT OnInsertTrigger( BSTR bstrData ); Parameters BSTRbstrData - comma delimited string containing all event data. ReturnHRESULT - NOERROR on success, or error code on Value failure.This method is used send data to all event subscribers as a single commadelimited string. Event interfaces may send most data types, but thisinterface currently only supports sending strings.

IXMCaSQLEvent::OnInsertTriggerEx

Syntax HRESULT OnInsertTriggerEx( BSTR bstrTime,     BSTR bstrAsset,    BSTR bstrState,     BSTR bstrSubState,     BSTR bstrData );Parameters BSTR bstrTime - string representing the time-stamp of thedata. BSTR bstrAsset - string containing the name of the asset fromwhich the data originated. BSTR bstrState - string containing the statedescription of the data item. BSTR bstrSubState - string containing thesub-state description of the data item. BSTR bstrData - stringcontaining the actual data. NOTE: optionally ‘real’ string data may bewrapped with quotes where as numeric data may not. For example thestring “foo” may be sent as “‘foo’”, where as the number “1.22” may besent as “1.22”. Return HRESULT - NOERROR on success, or error code onValue failure.

This method sends event data to each subscriber in a form where eachparameter is broken into a separate string for convenience.

A number of technologies may be used to implement the data routingsystem 720 or in conjunction with the data routing system 720. Themachine platform 730 may be implemented by, incorporate, or be connectedto a motion system as described in one or more of the following U.S.patents, the contents of which are incorporated herein by reference:U.S. Pat. No. 5,691,897; 5,867,385; 6,480,896; 6,513,058; and 6,885,898.

The data router 720 may be implemented by, incorporate, or be connectedto a data router system as described in one or more of the followingU.S. patent application, the contents of which are incorporated hereinby reference: Ser. No. 10/844,025.

The command processor 738 may be implemented by, incorporate, or beconnected to a motion system as described in one or more of thefollowing U.S. patent application, the contents of which areincorporated herein by reference: Ser. No. 10/991,905.

OPC technology, along with its formal specifications, forms an exampleof a protocol for implementing the Protocol Server. OPC is a softwaretechnology used to connect to various enterprise systems in theindustrial automation market, such as MES systems, machine monitoringsystems, and the like. Traditionally this technology has been used toconnect PLC and sensor data to such systems. Combining XMC with OPCprovides an elegant way to connect machine tool and motion control datainto these systems as well. For more information on OPC, seewww.opcfoundation.org.

The Microsoft SQL Database Server and related technologies may be usedto implement the server platform 732. The Microsoft SQL Database Serverdocumentation, which is available online, contains specific informationon how INSERT Triggers work and how one may call an external COM or COM+component.

The event system 734 may be implemented using the COM+ Event System. TheCOM+ Event System provides support for decoupled events. When decoupledevents are supported, both the data publisher and the data subscriberare independent of one another. Decoupled events are otherwise known asa loosely coupled event (LCE). COM+ Events are just one of the many COM+Services used by each of the components making up the system. Forexample, since the example protocol server 728 is a COM+ Application, itautomatically takes advantage of object pooling, and message queuecommunications provided by COM+.

The Microsoft COM (Component Object Model) describes the component modelthat all components described within the example system are based upon.

IV. Fourth Embodiment Enterprise System

Referring now to FIG. 44 of the drawing, depicted therein is an exampledata collection system 820 constructed in accordance with, andembodying, the principles of the present invention. The example datacollection system 820 comprises a connectivity server layer 822configured to collect data from at least one hardware device or asset824 through a machine platform 826. In the example data collectionsystem, the data collected by the connectivity server layer 822 isdistributed to a back office system layer 828.

The connectivity server layer 822 comprises a data routing system 830and a protocol server 832. The back office system layer 828 comprises atleast one enterprise software system 834. The assets 824 form a machinelayer 836, and the machine platform or platforms 826 form a platformlayer 838.

The data routing system 830 uses application called Enterprise Managerto configure, run and monitor a server technology that runs behind thescenes called the Enterprise Server. The Enterprise Server is thetechnology that actually collects data from the hardware device or asset824 in an intelligent manner. The enterprise software system 834 and theEnterprise Server form the data collection system 820.

The machine intelligence offered by the data routing system 830 allowsbetter data collection that shows how a machine asset 824 is operating.This machine intelligence infers the current state of the machine asset824 based on the state of given inputs and then sends the resultingoutputs to a desired data target for later analysis based on predefinedrules. Alternatively, data inputs read from each asset 824 may be sentdirectly up to the enterprise software for direct analysis at thatlevel.

There are several ways the data collection system 820 may be used tomonitor assets. The following discusses each of the configurationoptions that are available.

In FIG. 44, the data collection system 820 is illustrated in the contextof collecting data from a single asset 824. FIG. 44 illustrates how thedata routing system 830 is used along with the machine platform 826 toconnect an enterprise software system 834 to receive data from themachine asset 824.

A low-cost computer server PC may be used to run the software making upthe data collection system 820. In the example system 820, the datarouting system 830 is a software layer that ‘routes’ data from eachindividual asset 824 to various up-stream enterprise software systems834. The protocol server 832 provides connectivity to data itemsprocessed by the data routing system 830 using a protocol specification,such as may be developed by a standards body or other company or group.

The machine platform 826 is a controller neutral layer used for allcontroller communication that defines a universal API and variablemodel. Using the universal API and variable model of the machineplatform 826, data items easily flow from the target control of theasset 824 to the data routing system 830 for further routing to theenterprise software system 834. Typically the single instance model isonly used in environments where a dedicated computer is available foreach asset 824 that is to be monitored.

In situations where a PC is not dedicated to the target control system,the data collection system may be implemented using a multi-assetconnectivity model as shown at 840 in FIG. 45. The multi-asset modelallows for the connectivity server to communicate with two or moremachine assets 824 and route all data received from the group to one ormore enterprise software systems 834.

The example multi-asset data collection system 840 employs the datarouting system 830, protocol server 832, and enterprise software 834 asdescribed above. In addition, the example machine assets are identifiedas machine control industry products such as a GE/Fanuc asset 824 a,Siemens asset 824 b, Okuma asset 824 c, and a Mazak asset 824 d. Each ofthe assets 824 a-d connects to the data routing system 230 through anassociated machine platform 826 a, 826 b, 826 c, and 826 d.

By using multiple instances of the machine platform 826, the datarouting system 830 is capable of managing connectivity with a wide rangeof machine assets 824. Because the machine platforms 826 a-d arecontroller neutral, all of the example assets 824 a-d may be handled inthe same manner by the data routing system 830.

The example data collection systems 820 and 840 illustrate that thesesystems are capable of communicating to one or more target controllersor assets 826. As shown at 850 in FIG. 46, a data collection system ofthe present invention is also flexible enough to communicate withmultiple enterprise software systems 834 forming part of the back officesystem layer 828.

In particular, the data routing system 830 may be configured to connectto multiple enterprise software systems 834 as well. The example datacollection system 850 employs the data routing system 830, protocolserver 832, and enterprise software 834 as described above. Again, thedata routing system 830 collects data from the GE/Fanuc asset 824 a,Siemens asset 824 b, Okuma asset 824 c, and a Mazak asset 824 d throughthe associated machine platform 826 a, 826 b, 826 c, and 826 d. Inaddition, the data routing system 830 is capable of communicating withfirst, second, and third enterprise software systems 834 a, 834 b, 834c, and 834 d either directly or through the protocol server 823.

The enterprise software systems 834 may include: enterprise softwaresystems such as the systems 834 a and 834 b that communicate with thedata routing system 830 through the protocol server 832 (referred to asprotocol clients), enterprise software systems such as the system 834 cthat directly program to the data routing system 830 (referred to ascustom clients), and/or enterprise software systems such as the system834 d formed by an external database such as Microsoft SQL.

As described above, a data collection system of the present invention,such as the data collection systems 820, 240, and 850, are designed toroute data from one or more discrete motion based assets 824 to one ormore enterprise software systems 834. The example data collectionsystems 820, 840, and 850 employ a layered architecture comprising theconnectivity server layer 822, the back office layer 828, the hardwarelayer 836, and the machine platform layer 838. During the process ofrouting data from the assets 824 to the enterprise software systems 834,a general data flow takes place through this layered architecture.

Each of the layers 822, 828, 836, and 838 has a specific purpose, andthe purposes of these layers will be described below in the context ofFIG. 47.

The hardware layer 836 is the lowest layer. The target systems or assets824 define this hardware layer 836. As shown at step 1 in FIG. 47, thetarget systems or assets 824 produce the raw machine data describing thestate of the machine or asset 824 at any given point in time. Forexample, a machine used on the factory floor may produce machine statedata, whereas an RFID tag, global positioning locator or combination ofthe two, may produce the location and identification of a given asset824 at a point in time. As another example, a vehicle, boat or plane mayproduce data about its operating state in addition to its location, etc.

Each asset 824 is associated with a driver 860 designed to work with aspecific target system or asset 824. In particular, as shown at step 2,each driver 860 implements the target specific communication protocols,target specific language, and/or uses the target specific applicationprogramming interface (API) to collect the data from the target systemor asset 824. For example, a target system 824 may be a control systemused to run a machine on the factory floor. Alternatively the targetsystem may be a GPS locator, or RFID tag attached to an asset 824, orthe target system may be a control system within a vehicle, boat,airplane or other asset 824. In any of these examples, the driver 860 isconfigured at least to collect data its associated target system 824.

The machine platform 826 may be a motion server that, as shown at step3, makes all data received universal by providing a consistentprogramming interface and data model to up-stream software.

In the connectivity server layer 822, the data routing system 830 isconfigured to collect data from multiple assets 824 through multipleinstances of the machine platforms 826 such as one or more motionservers as shown at step 4. The data routing system 830 further maps alldata items received by the data routing system 830 from each asset 824to designer defined tags as shown at step 5. This model allows thedesigner to decide what data tags will make up their overall system thusallowing the overall architecture to better fit each enterprises needs.

Also in the connectivity layer 822, the protocol server 832 providesaccess as shown at step 6A to all data router data items defined aboveto any client application of the protocol server 832, such as one ormore of the enterprise software systems 834 as described above. Inaddition, as shown at step 6B, data items may be provided in a datarouter specific model so that custom enterprise applications 834 mayaccess the data item without using the protocol server 832.

In the back office layer 828, the enterprise software systems 834provide data analysis and storage of all data received as shown at step7.

Internally the data routing system 830 performs two tasks as it managesthe data pipeline: first, the data routing system 830 collects data froma set of assets 824; and second, the data routing system 830 then mapsthe data items to data tags that are sent along with the data to eachenterprise software system 834.

To route data from the assets 824 to the enterprise software system 834,the data routing system 830 employs user definable rules that map one ormore inputs to one or more outputs as generally shown in FIG. 48. Bydefault, each rule is configured to implement a pass-through that allowsthe raw data and data item to pass through to the enterprise softwaresystem 834.

Alternatively, each data item may also be fed into a set of rules thatallow combining data items and adding intelligence to each data itemthat fires. When a data output fires, associated actions take place. Forexample, when a data output fires it may send the raw data, its tag andany associated data (such as special codes, etc) to the targetenterprise software system 834. Optionally, the data outputs may firebased on the evaluation of the rules associated with each output. Rulesare evaluated against data inputs received from the machine platform826.

Referring now to FIG. 49, the data collection system 820 allows the userto add and configure the inputs, outputs, and rules that direct whichoutputs are to fire. The multi-layered software architecture implementedby the data collection system 820 allows for easily expandablecontroller connectivity that may take place independent of the detailsof any of the enterprise software systems 834. Simple plug-n-playdrivers may be added at a later date to already deployed systems in thefield thus making overall factory roll-outs easy to deploy over time.

The data collection system 820 uses a consistent interface between eachlayer in the architecture above, where each layer has its own individualpurpose as described in detail elsewhere. The data routing system 830 isa very modular component based system that allows for collecting datafrom various data sources and routing them to various data targets.Optionally, the data routing system 830 allows for the user to combinedata items and set rules that dictate when data items fire. All dataitems may be easily configured using an XML configuration file thatspecifies all data items, data sub-items and assets 824 in the system.

The protocol server 832 may be configured to provide connectivity to thedata router data items via data tags that are defined with the datarouter's XML configuration file. This model allows each system designerto easily configure their system and the data tags that make up theirsystem in a way that best suits their needs.

As shown in FIG. 49, the machine platform layer 838 may be configuredwith a MOTION.NET software system 862 and motion administrator 864 thatprovide programmatic access to the motion server 286.

With this software layer 838, the user can program to the motion server826 using virtually any language such as the Microsoft .NET languages,Java, C++ and Visual Basic 6.0. The data collection system 820 thus usesa component based model that is intuitive and easy to program.

Referring now to FIG. 50, the components making up the programming modelinclude the following:

-   -   A: The system component is the main component used to create all        others in the system. In addition, this component gives access        to a basic set of information describing the underlying target        control.    -   B & C: The program components are used to mirror the programs        currently managed by the target control.    -   D, E & F: The message components are used to get access to both        the alarm and operator messages on the target control. Both the        current and historical message data may be retrieved.    -   G & H: The tool components provide tool information such as tool        offset data, etc.    -   I & J: The workpiece components provide workpiece information        such as workpiece offset data, etc.    -   K: The direct connect component provides direct communication        access to the target controller.    -   L, M & N: The axis components provide axis information such as        axis positions, loads, axis type and axis name.    -   O: The event components provided event based updates of data to        upstream clients.    -   P, Q, R & S: The variable components allow for easy data access        via a universal variable model that not only allows for variable        assignment to control specific data items but also allows for        mapping directly to other motion platform API.

The example motion administrator 864 allows the user to configure eachinstance of the motion server 826, select the target control or asset824 used, and configure all configuration items specific to the controlselected.

The example motion server 826 provides a universal access point to theunderlying target controller. The example server 860 may be run as aWindows NT Service, as a serviced component, or stand alone, yet eachinstance is used to communicate with only one target controller. Usingthread, process, and reentrancy synchronization, the example motionserver 826 allows multiple instances to be run simultaneously tofacilitate communication with multiple control systems.

Each driver 860 is responsible for implementing all asset specific logicnecessary to communicate with the asset to read data from, write datato, and cause actions on the underlying system.

The hardware device or asset 824 may optionally embody a control systemand take the form of one or more of the following:

-   -   discrete or continuous assets on a factory floor used during a        manufacturing process;    -   discrete or continuous assets used during food processing;    -   a set of vehicles (e.g., a fleet of rental cars, a fleet of        semi-trucks used in shipping, logging or other transportation        uses, a fleet of police cars, a fleet of emergency vehicles, a        fleet of school or other types of busses, and/or a fleet of        construction tractors and trucks used at a construction site),        which may optionally use computer control systems to coordinate,        monitor or control the vehicles overall operation, internal        operation, or manner for which the engine, drive train, steering        or breaking operate;    -   farm equipment used to process agriculture either on the field        or during packaging and processing of the food products, which        may also use computer control systems in a similar manner as        described for vehicles above;    -   a set of boats or ships used for water transportation or        shipping, which may optionally use computer control systems to        coordinate, monitor or control the watercrafts overall        operation, internal operation, or manner for which the engine,        steering system, or ballast system operate;    -   a set of manned or unmanned airplanes or jets used for        exploration, data collection, surveillance, security,        transportation or shipping, which may optionally use computer        control systems to coordinate, monitor or control the aircrafts        overall operation, internal operation, or manner for which the        engine, flight controls, or other sensors operate;    -   a set of construction devices such as skill saws, digital        measuring devices, mixers used in construction, which may        optionally use computer control systems to coordinate, monitor        or control each devices overall operation, internal operation,        or motorized operation or parts used therein for that operation;        and/or    -   assets tagged with radio frequency identification (RFID) tags,        or global positioning systems (GPS), such as personnel working        in the field, animals within nature (such as wild game, or other        animal populations tracked for migration patterns), livestock or        other general inventory.

In the case of a mobile asset, the data may be stored by the asset forsubsequent uploading, or a mobile communications system may be usedbetween any two or more of the layers described above.

One of ordinary skill in the art will recognize that the presentinvention may be embodied in forms other than those described above. Thescope of the invention should be determined by the following claims andnot the foregoing detailed description of the example embodiments.

What is claimed is:
 1. A command processing system for transferring motion commands from at least one command source to at least one command target, where each command target supports at least one command target type, comprising: a set of motion commands; a set of command executives each capable of using at least one command target to execute at least one motion command; a command processor that is capable of routing at least one motion command from the set of motion commands to at least one command executive in the set of command executives; and a command source configured to communicate at least one communicated motion command with the command processor; wherein the command processor routes the at least one communicated motion command to at least one command executive; and the at least one command executive causes the motion command to be executed using at least one command target.
 2. A system as claimed in claim 1, wherein at least one motion command is capable of causing the motion control device to move an object.
 3. A system as claimed in claim 1, wherein at least one motion command is capable of querying motion related data from at least one command target.
 4. A system as claimed in claim 1, further comprising a source queue used when the command source communicates with the command processor.
 5. A system as claimed in claim 1, further comprising a target queue used when the at least one command executive communicates with at least one command target.
 6. A system as claimed in claim 1, further comprising a motion event containing motion related data received from at least one command target.
 7. A system as claimed in claim 6, wherein at least one motion event is received by the command processor.
 8. A system as claimed in claim 6, wherein at least one motion event is received by the command source.
 9. A system as claimed in claim 1, further comprising a client and a shared memory block wherein the client and the command processor communicate using the shared memory block.
 10. A system as claimed in claim 1, further comprising a client and a web service, wherein the client and the command processor communicate using the web service.
 11. A system as claimed in claim 1, further comprising an operating system service wherein the command processor runs within the operating system service.
 12. A system as recited in claim 1, further comprising a plurality of command targets.
 13. A system as recited in claim 1, in which the at least one command target is a motion control device. 